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KÖSZÖNTŐ 


Fülöp Miklós főszerkesztő-helyettes 


Kedves Olvasók! 

Elérkeztünk a Tech.Net magazin má- 
sodik számához. Az első számba 
bújt szarvashibák (nevezzük őket 
gyermekbetegségeknek...) után na- 
gyon kíváncsiak voltunk az olvasói 
visszajelzésekre. Hisszük, hogy la- 
punk hiányt pótol, de azt nem hit- 
tük volna, hogy ennyire nagy hatás- 
sal lesz a magyar Microsoft-felhasz- 
náló informatikusok világára. 
Magazinunk első számához az jutott 
hozzá, akinek a Microsoft Magyaror- 
szág ingyen adott: cégek, partnerek postán, vagy rendezvé- 
nyeken kapták kézhez lapunkat. Az újsághoz tartozó levele- 
zési lista azonban nyilvános, mindenki által elérhető, így 
tulajdonképpen az újságot megelőzte a híre. 

Itt érkeztünk el ahhoz a ponthoz, amire valójában (még) 
nem készültünk: az óriási érdeklődés mellett mindenki az 
előfizetési lehetőségekről kérdezősködött, mi pedig csak 
annyit mondhattunk: elnézést kérünk Uraim és Hölgyeim, 
ez a dolog valójában még nincsen kitalálva! Bevallhatjuk 
őszintén, nem számítottunk már az első hónapban ekkora 
érdeklődésre, tulajdonképpen az első szám megjelenése pil- 
lanatában fogalmunk sem volt arról, hogy ki, hogyan és mi- 
kor fogja terjeszteni az újságot. 

Azonnal nekifogtunk kidolgozni az előfizetési konstrukciókat 
(és az infrastruktúrát), mert már az a veszély fenyegetett, 
hogy fénymásolt kalózpéldányok kezdenek el terjedni, mint 
valami forradalmi lapnál... nos, kedves olvasók, az előfizetés 
mostantól működik. Aki szeretné, hogy lapunkat minden hó- 
napban biztosan megtalálja a postaládájában, nincs más dol- 
ga, mint ellátogatni a http: hnet.netacademia.net cím- 
re és ott megadni előfizetői adatait (ha úgy kényelmesebb, 
szívesen várjuk az e-maileket és faxokat is a túloldali imp- 
resszumban található címre és telefonszámra is). 

Második szám, mondtam, holott ez valójában nem igaz: a 
Microsoft Magyarország .net Enterprise bejelentésére idő- 
zítve megjelent első különszámunk is, benne a .net kiszol- 
gálócsalád (a volt BackOffice) tagjainak ismertetésével - 
ezúton is köszönjük a vezető informatikai cégek szakembe- 
reinek támogatását. A különszám szerkesztőségünkben 
megvásárolható, sőt, aki lapunkat egy évre előfizeti, az eh- 
hez - és a következő különszámokhoz is - jelentős kedvez- 
ménnyel juthat hozzá. 

Még egy utolsó gondolat az előfizetésről: olvasóink kérdez- 
ték, érdemes-e előfizetni, van-e jövője ennek a magazin- 
nak? Nos, mi hisszük, hogy van. Az informatikus szakem- 
bernek éjjel-nappal, szinte őrült tempóban kell követnie a 
változásokat. Ha valaki két hétre szabadságra megy (s mint 
tudjuk, a mobiltelefon, a laptop nem tűri jól a tengerparti 
homokot ;-) ), visszatértekor szinte tanulhatja újra a mes- 
terségét. Mi az újdonságok bemutatására törekszünk, és 
amíg újdonságok lesznek, addig reményeink szerint a 
tech.net magazin is talpon marad majd. Nyílvánvaló, hogy 
az érintett témák és azok mélysége meghatározza, egy- 





szersmint korlátozza az olvasói kör terjedését, de azt sze- 
retnénk, hogy aki ilyen típusú információra ,éhes", az meg- 
kapja tőlünk a havi betevőt. 

Egy másik olvasói megjegyzésre reagálva: nem célunk az, 
hogy eladjuk ezeket a termékeket, hanem az, hogy meg- 
könnyítsük azok professzionális használatát. Természetesen 
valamilyen szinten hiszünk az itt bemutatott technológiák- 
ban, különben nem lennénk itt, de az is lehet, hogy a tu- 
dásvágy, az újdonságok iránti érdeklődés hajt minket - és 
reméljük, olvasóinkat is. 

Célunk az, hogy bemutassuk az új lehetőségeket, lehetőleg 
szakmai szemmel, ezért hiányzik most - és nagy valószínű- 
ség szerint a jövőben is - lapunkból a játékleírás, a CD-mel- 
léklet. Nincs szándékunkban felvenni a versenyt a témával 
régebb óta, részletesen foglalkozó más lapokkal, és úgy érez- 
zük, erre tulajdonképpen nincs is szükség. Ha mégis valami 
olyan különleges, egyedi dologhoz jutunk hozzá, mint példá- 
ul egy nyilvános béta verzió, akkor előfordulhat, hogy meg- 
lepetésszerűen az újsághoz postázunk egy-egy fényes koron- 
got is, de egyelőre nem tervezünk hasonló akciót. Ha olyan 
szoftver jut a birtokunkba, ami széleskörű érdeklődésre tart- 
hat számot, és a méretbeli és jogi körülmények azt lehetővé 
teszik, inkább közzétesszük az újság készülő weblapján, 
ahonnan bárki letöltheti, akinek szüksége van rá. 

A tartalomról: a .net bejelentése ha lehet, még jobban fel- 
kavarja az informatika amúgy sem álló vizét. E számban 
vetkező számtól pedig esélyünk sincs arra, hogy ne erről 
beszéljünk: legyen a téma egykori BackOffice termék - most 
a .net Enterprise kiszolgálócsalád tagja; legyen fejlesztői 
környezet - mostantól Visual Studio.Net a neve; legyen az 
operációs rendszer, legyen Active Directory, legyen az új 
technológia - Windows 2000, Active Directory, XML, SOAP, 
WebDAV, mind-mind a .net-világ alapját képezi. Összefog- 
lalva a .net lényegét: bármit, bárhol, bármivel! 

Hogy ez a három varázsszó tulajdonképpen mit takar, arra 
a következő néhány hónapban fény derül majd. Mi a ma- 
gunk részéről annyit tehetünk, hogy ismertetjük ezeket az 
építőkockákat. Jelen számunkban mesélünk az Active 
Directory egyszerű programozásáról, az ADSI-ról, a .net 
egyik felhasználói eszközéről (surprise!) , az Office-ról, és az 
Office Server Extensions-ről, elárulunk néhány titkot az új 
SOL Server 2000-ről és még sok-sok másról. 


Jó böngészést kívánok! 
Fülöp Miklós 


mick Onetacademia.net 
MCSE, MCT 
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Microsoft .NET: Az Internet új generációja 


Microsoft 


Microsoft tanulmány - 2000. június 
Bevezetés: a forradalmi üzlet 

A számítástechnika a forradalmak ipara. Alig 20 éve még min- 
denki a mainframe-ről beszélt. Keveseknek adatott meg a szá- 
mitógépezés lehetősége, és nekik is többnyire egy cég számí- 
tástechnikai osztályán. A PC és a grafikus felhasználói felület 
ennek véget vetett: demokratizálta a számítástechnikát, hogy 
emberek milliói számára legyen elérhető, és valódi tömegcik- 
ké változtatta a számítógépet. A vállalatok felismerték, hogy a 
PC-s hálózatok és a PC-alapú kiszolgálók átalakíthatják üzlet- 
vitelüket, ugyanakkor a fogyasztók körében a PC rövid idő 
alatt házi szórakoztató eszközzé nőtte ki magát. Aztán meg- 
jelent az Internet. Forradalmasította a kommunikációt, meg- 
teremtette az információ és a szórakoztatás új és gazdag for- 
rását, és megtoldotta egy e betűvel a kereskedelmet. Ma kö- 
zel 300 millióan használják az Internetet. Az International 
Data Corp. szerint az Internet ebben az évben több mint 250 
milliárd dolláros üzleti forgalmat bonyolít le. 

Mindezek ellenére még rengeteg a fejlődési lehetőség. A 
mai Internet nagymértékben a régi mainframe-modellt tük- 
rözi. A sávszélesség bősége ellenére az adatokat most is 
központi adatbázisokban tárolják, amelyekhez a hozzáfé- 
rést ,kapuőrök" ellenőrzik. A korábbi időosztásos módszer- 
hez hasonlóan a felhasználóknak minden művelet elvégzé- 
sét a webkiszolgálóra kell bízniuk. A webhelyek elkülönült 
szigetek, amelyek a felhasználó nevében értelmes módon 
nem tudnak kapcsolatba lépni egymással. A web jelenleg 
alig több, mint olyan, egymástól független oldalak halma- 
za, amelyek nem az adatot, hanem annak HTML , képét" tar- 
talmazzák. (A legtöbb webhely esetében ma még mindkét 
feltétel teljesítése túl nagy követelményt jelentene.) Sok te- 
kintetben a böngészők sem többek buta termináloknál: az 
adatok keresése könnyű, ellentétben a szerkesztéssel, elem- 
zéssel és manipulációval (azaz minden olyan dologgal, ami- 
re egy tudásalapú rendszerben szükség lehet). A testreszabás 
eredményeként a meglátogatott webhelyek által kért sze- 
mélyes adatok egymással átfedésben vannak, ráadásul az 
ellenőrzésükről is le kell mondanunk. Ahelyett, hogy a 
technológia alkalmazkodna hozzánk, nekünk kell alkalmaz- 
kodnunk a technológiához. 

Több PC vagy hordozható eszköz használatakor ezek a prob- 
lémák fokozottabban jelentkeznek. Az online információk, 
elektronikus levelek, offline fájlok és más adatok elérését 
megnehezíti a - gyakran inkompatíbilis — csatolófelületek 
végtelen változatossága, az adathozzáférés többféle szintje 
és a szinkronizáció korlátozott lehetősége (ami a hordozha- 
tó eszköz és a PC fizikai összekapcsolását jelenti). Az online 
adatokat hiányosan definiálják, ami nagymértékben korlá- 
tozza a felhasználásukat. A szükségleteinkhez alkalmazko- 
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dó testre szabott ,személyi információs tér" koncepciója 
egyelőre még álom. 

A webhelyek tervezésére, tesztelésére és kivitelezésére 
szolgáló fejlesztői eszközök nem megfelelőek. Sokszor na- 
gyobb hangsúlyt fektetnek a külalakra, mint a használható- 
ságra, és egyik sincs tekintettel a szoftvereknek a terve- 
zést, fejlesztést, kivitelezést, üzembehelyezést és karban- 
tartást is átfogó teljes életciklusára. Jelenleg nincs lehető- 
ség arra, hogy a PC-re írt kódot különféle eszközökön vál- 
toztatás nélkül használhassuk. 

A vállalati felhasználóknak további kihívásokkal is szembe 
kell nézniük. Bár a kisebb kiszolgálókból álló fürtök az egy- 
pontos hibák kiküszöbölésével növelték a megbízhatóságot, 
a rendszerfelügyelet bonyolultabbá vált. A mai többszintű 
és többfunkciós webhelyek teljesítményének mérése, kapa- 
citásának tervezése, üzemeltetése nem egyszerű feladat. Az 
új e-kereskedelmi és a hagyományos üzleti rendszerek meg- 
feleltethetősége vagy együttműködése ritka. A fogyasztók 
és partnerek számára a vállalati információs rendszer meg- 
felelő használatát biztosító, a tűzfalon keresztül biztonsá- 
gosan működő rendszerek tervezése olyan nehéz, hogy sok 
vállalat inkább a költségesebb megkétszerezést választja. 
Tényleg olyan jó lesz az Internet, amilyennek most látjuk? 
A web további fejlődését senki sem kérdőjelezi meg, de ah- 
hoz, hogy ez valóban hasznos legyen a feljesztők, a válla- 
latok és a vásárlók számára, egy új, radikális vízió is szük- 
séges. A Microsoft célja ennek a víziónak és a megvalósítá- 
sához szükséges technológiának a megteremtése. 


Microsoft.NET: a böngészők és a .COM világán túl 

A Microsoft olyan fejlett szoftvergenerációt hoz létre, 
amely a számítástechnikát és a kommunikációt forradalmi 
módon egyesíti, a fejlesztők számára pedig eszközöket 
nyújt a web és a számítástechnika más területeinek átala- 
kítására. A Microsoft.NET az első olyan kezdeményezés, 
amely a fejlesztők, vállalatok és vevők számára biztosítja, 
hogy a saját elképzeléseik szerint hasznosíthassák a számí- 
tástechnika lehetőségeit. Lehetővé teszi valódi elosztott" 
webszolgáltatások készítését, amelyek a kiegészítő szolgál- 
tatások együttműködésével a .COM rendszereknél lényege- 
sen jobb kiszolgálást valósítanak meg. Az Internet követke- 
játszik, mert az adatokat bármikor, bárhol és bármely esz- 
közön elérhetővé teszi. 

A Microsoft.NET a figyelmet az egyedi webhelyekről és 
Internetre kapcsolt eszközökről a számítógépek, eszközök és 
szolgáltatások olyan együtteseire irányítja, amelyek az 
együttműködésük révén az eddigieknél sokoldalúbb megol- 
dásokat nyújtanak. A felhasználókon múlik, hogy milyen 
adatok, hogyan és mikor jutnak el hozzájuk. E széleskörű 
együttműködés révén megszűnnek az elszigetelt szolgáltatá- 
sok, ahol az integrációt maguk a felhasználók végezték el. A 
vállalatok képesek lesznek oly módon kínálni termékeiket és 
szolgáltatásaikat, hogy a vásárlók transzparensen beilleszt- 
hessék ezeket saját elektronikus rendszerükbe. Ez a vízió to- 
vább növeli a PC-k 1980-as évekbeli megjelenésével kiala- 
kult személyi szabadságot. 
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A Microsoft.NET elősegíti az Internet átalakulását, ami a 
HTML alapú oldalak kiterjesztését jelenti programozható, 
XML alapú formába. Az XML széles körben elfogadott ipari 
szabvány, melyet a World Wide Web Consortium hozott lét- 
re. Nem kizárólagosan a Microsoft nevéhez fűződő techno- 
lógia, bár a kidolgozásában jelentős szerepet vállalt a cég. 
Az XML segítségével az adat teljesen elválasztható a meg- 
fontosságú eleme: az adatok ,felszabadításával" meg- 
könnyíti a weblapok tervezését, programozását és javítá- 
sát; hatékonyabbá teszi az adatok elosztását; lehetővé te- 
szi webhelyek, illetve egymással kapcsolatot teremteni ké- 
pes webszolgáltatások együttműködését. 

A Microsoft.NET-et a következő elemek alkotják: 

0  Microsoft.NET platform - Magában foglalja a szolgál- 
tatások új generációjának készítésére és üzemeltetésére 
alkalmas .NET infrastruktúrát és eszközöket; sokoldalú 
ügyfélprogramok készítését elősegítő .NET felhasználói 
felületet; a nagymértékben elosztott megaszolgáltatá- 
az internetes eszközök új nemzedékét támogató .NET 
szoftvereket. 

Microsoft.NET termékek és szolgáltatások 
Tartalmazza a Windows.NET-et, amelybe integrálták a 
legfontosabb szolgáltatásmodulokat: az MSN.NET-et; 
egyéni előfizetési szolgáltatásokat, az Office.NET-et; a 
Visual Studio.NET-et, és a bCentral for .NET-et. 
Kívülálló cégek.NET szolgáltatásai - Számos párt- 
nernek és fejlesztőnek lesz lehetősége a .NET plat- 
formra épülő vállalati és vertikálisan integrálható szol- 
gáltatások készítésére. 

A Microsoft.NET a számítástechnikában és a kommunikáci- 
óban jelentős elmozdulást eredményez az egyirányú 
webtől egy sokoldalú, együttműködésre képes, interaktív 
környezet felé. A Microsoft.NET új, fejlett szoftverek segít- 
ségével aknázza ki az alkalmazások, szolgáltatások és esz- 
közök együttesét a testre szabott digitális élmény megte- 
remtéséhez, amely folyamatosan és automatikusan alkal- 
mazkodik a felhasználók, családok, otthonok, munkahelyek 
igényeihez. Ez egy integrált szolgáltatásként működő új 
szoftvergenerációt jelent, amely az Internet korszakában 
megkönnyíti életünk és munkánk szervezését. 

Mit jelent ez a különböző szereplők számára? 

0 Fogyasztók: a szolgáltatások integrációjából fakadó egy- 
szerűség. Dokumentumok készítésének, szerkesztésé- 
nek és böngészésének egységesítése. Fájlok, munka- 
anyagok és egyéb média online és offline elérése. Az 
eszközök által nyújtott holisztikus élmény. Teljeskörű 
testre szabás-nincs menedzsment. Ez például azt jelen- 
ti, hogy a megváltozott adatok - történjen az adatbe- 
vitel akár egy PC-ről vagy egy hitelkártyáról - azonnal 
és automatikusan elérhetők lesznek bárhol, ahol éppen 
szükség van rájuk. j 
Tudásalapú rendszerek és vállalatok: dokumentumok 
készítésének, szerkesztésének és böngészésének egysé- 
gesítése. Sokoldalú, irányított kommunikáció. A hor- 
dozható eszközök nem követelnek többlettudást a fel- 
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használóktól. Hatékony adatkezelési és e-kereskedelmi 
eszközök, amelyek transzparensen váltogatnak a belső 
és Internetalapú szolgáltatások között, valamint támo- 
gatják a dinamikus kereskedelmi kapcsolatok új korsza- 
kának kialakulását. 

-? Független szoftverfejlesztők: lehetőség az Internet- 
korszaknak megfelelő új, fejlett szolgáltatások készíté- 
sére, amelyek az eszköztől vagy a nyelvtől függetlenül 
képesek az adatok helyi vagy távoli, automatikus eléré- 
sére és módosítására anélkül, hogy a kódot minden 
egyes környezethez újra kellene írni. Minden, ami az 
nak építőeleme lehet, ugyanakkor minden alkalmazás 
működhet internetes szolgáltatásként is. 

A Microsoft.NET víziója szerint a fogyasztók, vállalatok, 

szoftverfejlesztők és a teljes ipar hatákonysága növekszik, 

az Internet - béklyóitól megszabadulva - kiteljesedhet, és 
végre olyan lesz, amilyennek mi, felhasználók szeretnénk. 


A Microsoft.NET platform: az Internet új generáció- 
jának építése 

Microsoft.NET platform olyan forradalmi modell, amely al- 
kalmas egy új és feljett szoftvergeneráció kifejlesztésére. 
A programozási modellek korábban egyetlen rendszerre 
összpontosítottak, és a más rendszerekkel való kapcsolato- 
kat is úgy próbálták ábrázolni, hogy azok helyinek látssza- 
nak. A Microsoft.NET-et kifejezetten arra tervezték, hogy 
az Internet erőforrásai integrálhatók legyenek egyetlen 
megoldássá. Az integrációnak ez a fajtája ma bonyolult és 
költséges, de a Microsoft.NET ezt a szoftverfejlesztés lé- 
nyegi elemévé teszi. 

A lazán kapcsolt, XML alapú Microsoft.NET programozási 
modell bevezeti az XML alapú webszolgáltatások készítésé- 
nek koncepcióját. Míg a mai barkácsolt webhelyek további 
jelentős fejlesztés nélkül képtelenek társaikkal együttmű- 
ködni, a Microsoft.NET programozási modellje erre könnye- 
dén képes webhelyek és -szolgáltatások készítését teszi le- 
hetővé. A Microsoft.NET úgy fogja elősegíteni az Internet 
felváltani képes alkotóelemek megjelenése felgyorsította 
az ipari forradalmat. 

De mindez nem jöhet létre a sok-sok partner, illetve függet- 
len és vállalati fejlesztő nélkül, akik közreműködtek a mai szá- 
mítástechnikai ipar kialakításában; vagy ahogy Alexander 
Graham Bell fogalmazott: , A nagy felfedezések és fejlesztések 
mögött mindig számos elme együttműködése áll." A követke- 
ző három évben a Microsoft 2 milliárd dollárt fordít arra, hogy 
az üzleti partnerek, a független fejlesztők és a vállalati IT fej- 
lesztők Microsoft.NET szolgáltatásokat készíthessenek. 

A fejlesztőknek a Microsoft a Microsoft.NET fejlesztőeszkö- 
zök olyan új családját hozza létre, amelyet egészen az ala- 
poktól terveznek meg a web, az ügyfél- és szerveralkalma- 
zások, illetve a szolgáltatások számára. Ezekkel az eszkö- 
zökkel a fejlesztőknek lehetőségük nyílik a jelenlegi, az 
adatokat statikusan megjelenítő webet úgy átalakítani, 
hogy az interaktív szolgáltatások hangsúlyos szerepet kap- 
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janak. A Microsoft áttörést jelentő Visual Studio eszköz- 
készlete automatizálta a webszolgáltatások készítését a 
gyors alkalmazáskészítést segítő drag-and-drop módszerrel, 
amelyben úttörő szerepet játszott a Visual Basic fejlesztő- 
rendszer. Ezek a szolgáltatások már bármely XML-t értő 
platformon használhatók. A Visual Studio az XML kódot au- 
tomatikusan készíti el. A Microsoft egy új BizTalk eszköz- 
rendszer megjelenését is hirdeti, amellyel, a megfelelő 
szolgáltatások összeállításával, vizuálisan programozha- 
tunk üzleti folyamatokat. A vállalati elemzők így azokkal a 
módszerekkel hozhatnak létre megoldásokat, amelyekkel a 
fejlesztők is dolgoznak. 
A Microsoft.NET programozási modellben a független fej- 
lesztőknek kevesebb erőforrásra kell koncentrálniuk annak 
függvényében, hogy az alkalmazások hol és hogyan fut- 
nak, de leginkább, hogy mit csinálnak, vagyis, hogyan 
tudnak valódi értéknövelést elérni. A Microsoft.NET a fej- 
lesztőket érintő nagy kihívások közül például a kezelhető- 
ség és a használhatóság közötti eltolódással is foglalkozik. 
Az alkalmazásszolgáltatás új elemekkel bővül: bármely más 
alkalmazással integrálhatók, testre szabhatók, programoz- 
hatók és offline módban is futtathatók. 
Mivel a legfontosabb Microsoft.NET szolgáltatások előfizet- 
hetők, a fejlesztők dönthetnek a vásárlás vagy a saját meg- 
oldás mellett, annak függvényében, hogy mire akarják fordí- 
tani a fejlesztési erőforrásokat. Egyesek szavazhatnak a házi 
fejlesztésre, de a legtöbben valószínűleg egy jól elkészített 
megoldáscsomag mellet teszik le a voksot, amelyhez komoly 
fejlesztőeszköztámogatás is tartozik. Kevesen írnak a Win- 
dowshoz saját nyomtatómeghajtót vagy ablakkezelő rend- 
szert. A legtöbben ehelyett inkább a magasabb szintű saját 
termékeik differenciálására koncentrálnak. 

A legfontosabb Microsoft.NET szolgáltatásmodulok kínála- 

ta a következő lesz: 

0 Azonosítás: A Microsoft Passport és Windows hitelesíté- 
si technikára épülve a hitelesítés többféle szintjét 
nyújtja, a jelszavaktól és a tárcáktól kezdve az elek- 
tronikus hitelesítő kártyákig és a biometrikus eszközö- 
kig. Segít olyan szolgáltatásokat készíteni, amelyek 
biztosítják a testreszabhatóságot és az adatbiztonsá- 
got az ügyfeleknek, akik így biztonságosabban férhet- 
nek hozzá a szolgáltatásaikhoz, függetlenül attól, hogy 
hol vannak, vagy milyen eszközt használnak. 

-0 Értesítés és üzenetküldés: Egyesíti az azonnali üze- 
netküldést, az elektronikus levelezést, a faxot, a hang- 
postát és az értesítés, illetve üzenetküldés más formá- 
it egy egységes megjelenésű, PC-re vagy más kommu- 
nikációs eszközre alkalmazható megoldássá. A web- 
alapú Hotmail elektronikus levelezési szolgáltatásra, 
az Exchange-re és az Instant Messenger-re épül. 

2 Testreszabás: Lehetőséget ad a felhasználóknak sza- 
bályok és preferenciák készítésére, amelyek implicit és 
explicit módon meghatározzák, hogyan kell kezelni az 
értesítéseket és üzeneteket, az adatmegosztási kérel- 
meket, és az olyan helyzeteket, amikor több eszközt is 
használnak (például a laptop mindig legyen szinkroni- 
zálva a Microsoft.NET tárolószolgáltatással). Az adatok 
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feltöltése egy új PC-re így egyszerű és gyors lesz. 

2 XML tároló: Univerzális nyelvet (XML) és protokollt 
(SOAP) használ az adatok jelentésének leírására. Így 
lehetővé válik az adatok integritásának megőrzése ak- 
kor is, ha azok átvitele és kezelése több webhely és 
felhasználó között történik. Ennek eredményeképpen a 
webhelyek rugalmas, interakcióra képes szolgálta- 
tásokká válnak, amelyek képesek egymás adatainak fel 
használására. A Microsoft.NET az adatok tárolására egy 
biztonságos és címezhető helyet is kínál. Ez bármely 
eszközzel elérhető, miközben replikációval a haté- 
konyság és az offline használat is biztosítható. Mások 
tárolóhelyének használata a tulajdonos beleegyezé- 
sével lehetséges. Egyesíti az NTFS, az SOL Server, az 
Exchange és az MSN szolgáltatásait. 
Naptár: A felhasználói vezérlés sarkalatos pontja az 
idő. Mikor lehet valakit zavarni, és mikor hagyják őt 
békén? Ez a kérdés egyre fontosabb lesz, ahogy egyre 
több eszközt egyre több ideig használunk, és ahogy a 
felhasználók és a szolgáltatások közötti kapcsolat egy- 
re gyakoribbá válik. A Microsoft.NET biztosítja az álta- 
lános, munkahelyi és otthoni naptárak egyesítését, 
úgy, hogy azok bármely eszközzel, más szolgáltatások, 
egyének számára is elérhetők legyenek. Az üzenetkül- 
désre és együttműködésre alkalmas Outlook ügyfél- 
programra és a Hotmail naptárra épül. 

0 Címtár és keresés: A Microsoft.NET lehetővé teszi 
azoknak a személyeknek és szolgáltatásoknak a 
megtalálását, amelyekkel fel kell venni kapcsolatot. A 
Microsoft.NET címtárak többek egyszerű keresőmoto- 
roknál vagy , arany oldalaknál". Programozható módon 
képesek kapcsolatba lépni szolgáltatásokkal, és választ 
tudnak adni egyes sémaalapú kérdésekre is, amelyek a 
szolgáltatások képességeire vonatkoznak. Más szol- 
gáltatásokkal együtt is alkalmazható, illetve össze- 
vonható vagy testreszabható. 

-" Dinamikus kézbesítés: Biztosítja a Microsoft és a fej- 
lesztők számára, hogy a funkcionalitást inkremen- . 
tálisan növeljék, és igény szerinti megbízható, auto- 
matikus frissítést hajtsanak végre anélkül, hogy a fel- 
használónak bármit is telepítenie vagy beállítania kel- 
lene. A Microsoft.NET bármely eszközön proaktív mó- 
don alkalmazkodik ahhoz, amit a felhasználó tenni 
szándékozik. Egy olyan világban, ahol a felhasználók 
több eszközön szeretnék élvezni a szolgáltatások elő- 
nyeit, a hagyományos, telepítésfüggő alkalmazásmo- 
dell fordítottjára van szükség. 

A Microsoft.NET elosztott szolgáltatásai online és offline is 

elérhetők lesznek. Egy helyi kiszolgáló által biztosított, 

vagy az Interneten elérhető szolgáltatás olyan önálló gé- 
pen is használható lesz, amelyik nem kapcsolódik az 

Internetre. A különféle elemek együttműködhetnek, vagy 

adatokat cserélhetnek egy , szövetségnek" nevezett folya- 

mat segítségével, amely a szervezetek számára lehetővé 
teszi, hogy eldöntsék, saját, vagy egy külső, más által 
szolgáltatott infrastruktúrát használjanak anélkül, hogy 
meg kellene alkudniuk a szolgáltatások szabályozása vagy 
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hozzáférése tekintetében, akár az Interneten, akár más- 
képpen veszik igénybe. Így például egy vállalati címtár- 
szolgáltatás ,szövetségre léphet" más szolgáltatással az 
Interneten. A Microsoft.NET-en alapuló szolgáltatások 
messze túlhaladják azt, amit a mai internetalapú szolgál- 
tatások kínálni tudnak. 

A Microsoft.NET szolgáltatásmoduljai minden XML-t támogató 
platformon használhatók. A Windows biztosítja a legmegfele- 
lőbb környezetet a webszolgáltatások készítésére és kézbesíté- 
sére, míg a Windows-alapú ügyfélprogramokat úgy optimali- 
zálják, hogy a webszolgáltatások mindenféle eszközön hasz- 
nálhatók legyenek. A Microsoft Windows DNA 2000 rendelke- 
zett először átfogó, XML-t támogató infrastruktúrával, amely- 
lyel webszolgáltatások készíthetők és üzemeltethetők. 


Microsoft.NET felhasználói felület: intelligens kap- 
csolatkezelés 

A számítástechnika jelenleg két világra osztható: a PC-ken és 
más eszközökön futó alkalmazások világára és a webhelyek 
világára. A Microsoft.NET lehetővé teszi a két világ közti 
együttműködést, miközben párosítja a gazdag funkcionalitást 
az Internet végtelen adattengerével. A mai webet a Tim 
Berners-Lee által előrevetített , interkreatív térré" alakítja át. 
Az online és offline környezetben való munka ma kellemet- 
len és nem túl hatékony - még akkor is, ha csak egyetlen 
PC-vel dolgozunk. Egyáltalán nem integrált a web- 
böngészés (csak olvasás), az alkotás (dokumentumok írása 
és szerkesztése), a kommunikáció (elektronikus levél, azon- 
nali üzenetküldés), a kalendárium és címjegyzék (offline, 
eszközfüggő). Mind más alkalmazást igényel, amelyek 
funkcionalitása és kompatibilitása erősen változó. Legtöb- 
bünk egyetlen olyan egyesített, eszközfüggetlen környeze- 
tet szeretne, amely ahhoz a környezethez alkalmazkodik, 
amelyben éppen dolgozunk, transzparensen váltogatva a 
helyi és távoli szolgáltatások, illetve alkalmazások között 
- ez lenne az internetkor univerzális felülete. Ennek meg- 
valósításához a Microsoft.NET a következőket kínálja a fel- 
használóknak: 

-0 Természetes kezelőfelület: Olyan technológiák gyűj- 
teménye, amelyek az ember és számítógép közti kom- 
munikáció új generációját valósítják meg - ide tartozik 
a beszéd, a látvány, a kézírás, és egy újfajta adatbevi- 
teli ablakban, természetes nyelven történő bevitel. 
Ezek a megoldások kombinálhatók egy felhasználói fe- 
lületben. A természetes kezelőfelület bármely eszközön 
vagy környezetben biztosítja a megfelelő felhasználói 
felületet. 

Univerzális felület (canvas): XML-el ötvözött infor- 
mációs architektúra, amely egyesíti a böngészést, a 
kommunikációt és a dokumentumok készítését egyet- 
len egységesített környezetben, egységes módon téve 
lehetővé az adatok elérését és szintetizálását. Az uni- 
verzális felület az XML-re épülve átalakítja a csak ol- 
vasható Internetet írható-olvashatóvá, ami a felhasz- 
nálók számára megnyitja az utat az adatok interaktív 
böngészése, szerkesztése, jegyzetekkel való ellátása és 
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vizsgálata előtt. Mivel az XML szolgál alapul, az univer- 
zális felület a különböző forrásból származó adatokat - 
a világ bármely részéről is származzanak - képes egye- 
síteni, megvalósítva ezzel az adatok transzparens hoz- 
záférését, szintetizálását és használatát. 

"5 Adatügynök: Kezeli a felhasználó személyazonosságát 
az Interneten, és fokozottabb ellenőrzési lehetőséget 
biztosít a webhelyek és -szolgáltatások felhasználóval 
való kapcsolatteremtése felett. Kezeli a meglátogatott 
oldalak listáját, a kontextust és a preferenciákat - a 
felhasználó múltját, jelenét és jövőjét az Interneten. 
Támogatja az adatbiztonsági technológiákat, például a 
PgP-t. A mai Internettel ellentétben az adatok a 
felhasználó ellenőrzése alatt maradnak, és ő dönt arról, 
ki férhet hozzá, és ki nem. Elég az egyéni preferen- 
ciákat egyszer elkészíteni, majd engedélyezni haszná- 
latát a kiszemelt webhelyek vagy szolgáltatások számára. 

0 Smarttag: Az IntelliSense technológia kiterjesztése a 
webtartalomra, ami lehetővé teszi, hogy a PC és más 
eszközök intelligensen kezeljék az Internetről vett 
adatokat. A kiterjeszthető architektúra bárki számára 
biztosítja az alkalmazkodó felhasználói felület és 
adatkezelők elkészítését. Az XML sémák alapja. 

Az intelligens eszközök új nemzedékével dolgozva a 

Microsoft.NET-et a felhasználó ott használja, ahol akarja. 

képesek legyenek mások szolgáltatásait használni, és jó 

adatfeldolgozó-kapacitással rendelkezzenek. A hálózatot 
intelligensen használják, kiaknázzák a széles sávú kapcso- 

latokat, de takarékosak a vezeték nélküli kapcsolatoknál. A 

programozhatóság, a testreszabás és az automatikus frissí- 

tés lehetősége, illetve az adminisztrációs igény eltűnése 
miatt ezek az új, intelligens eszközök robbanásszerűen el- 

terjednek a következő öt évben, és méltó társai lesznek a 

legfőbb intelligens, internetes eszköznek: a PC-nek. 


Microsoft.NET: a termékek és szolgáltatások új generációja 
Hosszú távon az összes alkalmazás szolgáltatásként lesz el- 
érhető, amelyre az Interneten lehet majd előfizetni. A Mic- 
rosoft és a többi alkalmazásszolgáltató számára ez annyit 
jelent, hogy színvonalasabban tudják a fogyasztókat kiszol- 
gálni, a telepítés és a biztonsági mentés központosított 
lesz, és pozitív visszacsatolás jön létre a termékfejlesztés- 
hez. A szolgáltatásként elérhető alkalmazások azt is lehe- 
tővé teszik a Microsoft és más független fejlesztők számá- 
ra, hogy gyorsabban tudják megoldani a biztonsági mentés 
és a vírusvédelem problémáit. 
Úgy képzeljük, hogy alkalmazói szoftvereink többsége idő- 
vel előfizethető szolgáltatássá alakul, miközben továbbra 
is kínáljuk meglévő platformjainkat és alkalmazásainkat. A 
Microsoft azonban már kezdettől fogva ajánlani fog egy 
sor .NET terméket. Ezek közül néhány: 
2 Windows.NET: A Windows új generációja, amely előse- 
gíti a termelékenységet, az alkotást, a kezelhetőséget, 
a szórakoztatást és még sok mást. Úgy tervezték, hogy 
a felhasználók teljes mértékben ellenőrzésük alatt tart 
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hassák életük digitális részét. A .NET legfontosabb 
szolgáltatásmoduljaival szorosan integrálták, így 
amellett, hogy személyre szabható, beépített támo- 
gatást nyújt a digitális anyagok és az együttműködés 
számára. Programozhatók a .NET szolgáltatásokkal, 
mint például az MSN.NET, a bCentral for .NET és az 
Office.NET. A Windows.NET sokoldalú platformot biz- 
tosít a .NET alkalmazásokat és szolgáltatásokat író fej- 
lesztők számára. A Microsoft továbbra is kínálja és tá- 
mogatja a Windows platform különféle verzióit .NET 
szolgáltatások nélkül. 

0 MSN.NET: Ötvözi az MSN legfontosabb tartalmi eleme- 
it és szolgáltatásait a .NET platformmal. A felhaszná- 
lóknak így lehetősége nyílik egyedi digitális sze- 
mélyazonosítók készítésére, illetve az intelligens szol- 
gáltatások elérésére, amellyel biztosítható az adatok, 
szórakozási lehetőségek és személyek konzisztens, 
transzparens és biztonságos elérése, bármikor, bárhol 
és bármely eszközről. Az MSN.NET egy jelenleg béta fá- 
zisban lévő ügyfélprogramra fog épülni. 

-0 Egyéni előfizetési szolgáltatások: Az MSN.NET mel- 
lett a Microsoft olyan .NET-alapú, fogyasztóközpontú 
szolgáltatásokat is készít, amelyek a jelenlegi szórakoz- 
tató- és játékprogramokra, illetve oktatásban és terme- 
lésben résztvevő termékekre épülnek. A felhasználók 
számára ezek a szolgáltatások a hagyományos munka- 
asztali alkalmazások előnyeit a felhasználói felületek 
és helyváltoztatási támogatásával képesek ötvözni. 

0 Office.NET: Fejlett kommunikációt és termelést előse- 
gítő eszközök. Ilyen például az univerzális felület, 
amely a kommunikációt, a böngészést és a dokumen- 
tumszerkesztést egyetlen környezetbe olvasztja, és ez- 
zel biztosítja, hogy a felhasználók egységes módon 
tudják elérni az adatokat. Az univerzális együttmű- 
ködési szolgáltatásokkal bárki együttműködhet más 
vállalati dolgozókkal, vagy akár vállalaton kívüli sze- 
mélyekkel is. Intelligens ügyfélprogramokra és szolgál- 
tatásokra épülő, új architektúra, amely sokféle képes- 
séggel, nagy teljesítménnyel és bármely eszközön au- 
tomatikus telepítési lehetőséggel rendelkezik. A Micro- 
soft továbbra is kínálja és támogatja a .NET szolgálta- 
tások nélküli Office verziókat. 

7 Visual Studio.NET: Az MSDN és a Windows DNA kiszol- 
gálók által teljes mértékben támogatott, XML alapú 
programozási modell és eszközök. Megkönnyíti a nagy 
mértékben elosztott, programozható szolgáltatások 
készítését, amelyek magukban álló gépeken, vállalati 
adatközpontokban és az Interneten futnak. 

0 bCentral for .NET: Élvonalbeli, előfizetésalapú szolgál- 
tatások és eszközök kis- és növekvő vállalatoknak. Ma- 
gába foglalja a külső szolgáltatásként működő üzenetkül- 
dést és elektronikus levelezést, fejlett kereskedelmi 
szolgáltatásokat és a vevőkapcsolatokat kezelő új szol- 
gáltatást, amely a .NET platformra épül. A kisvállalatok 
ezek segítségével színvonalasabb online szolgáltatást 


tech.net 


nyújthatnak vásárlóiknak. Támogatja a külső katalógu- 
sok használatát, és figyelemmel kíséri a fogyasztók te- 
vékenységét a személyre szabott szolgáltatás megvaló- 
sítása érdekében. 


Következtetés: a .NET forradalom 

Tíz évvel ezelőtt a Microsoft olyan világot álmodott meg, 
amelyben az adatok szinte , megérinthető közelségbe" ke- 
rülnek hozzánk. Akkoriban az adatok elérése 4800 baud se- 
bességű kapcsolaton folyt, az üzeneteket nem elektronikus 
levélben, hanem faxon küldték, és még csak kevesen hal- 
lottak az Internetről. Bár ebben a világban a felhasználók 
határozzák meg, hogy milyen adatokat, honnan és milyen 
eszközről akarnak elérni, akkor még nem lehetett tudni, 
hogy ennek megvalósításában milyen eszközök segítenek 
majd bennünket. Ma már tudjuk. 

A Microsoft.NET platform a XXI. század első évtizedében for- 
radalmasítja a számítástechnikát és a kommunikációt, mivel 
elsőként használja ki teljes mértékben mindkettő előnyeit. A 
számítástechnika és a kommunikáció egyszerűbbek lesznek, 
életre, és sokezer fejlesztő hozhat létre forradalmian új, on- 
line szolgáltatásokat és üzleteket. A felhasználóknak több 
irányítási lehetőséget ad a kezébe, amellyel jobban ellenőriz- 
hetik a digitális azonosítójukat és a magánjellegű adataikat. 
Ami ezt lehetővé teszi: a szoftver. 

A Microsoft.NET akkor lesz sikeres, ha sikerében mások is 
jelentős szerepet vállalnak. A Microsoft üzleti filozófiája 
mindig az olcsó és jó teljesítményű szoftverek tömeggyár- 
tása volt, amik segítik a magán- és üzleti felhasználókat 
tevékenységükben, továbbá vásárlóink, partnereink és a 
független fejlesztők számára új lehetőségeket tárnak fel. 
Ez a filozófia különbözteti meg a Microsoftot versenytársa- 
itól, amit a Microsoft.NET tovább erősít. 
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A DNS (Domain Name System - tartománynév-szolgál- 
tatás) használata 

A tartománynév-szolgáltatás vagy más néven DNS használata 
minden Internethez csatlakozó szervezet életében létfontossá- 
gú. A DNS hozzárendelést végez a köznapi nevek (példá- 
ul www. netacademia.net) és a kommunikációhoz hasz- 
nált IP-címek között. Az Active Directory a DNS szolgáltatása- 
in alapul: a DNS segítségével keressük meg például az Active 
Directoryban szereplő számítógépek IP címét, s ezzel magát a 
gépet. Ez alapvető változás a korábbi Windows operációs rend- 
szerekhez képest, melyek NetBIOS neveket rendelnek az IP- 
címekhez, s amelyek WINS, vagy egyéb NetBIOS névhozzáren- 
delési szolgáltatásra támaszkodnak. 

Az Active Directory a Windows 2000 alapú DNS kiszolgálók- 
kal működik együtt a leghatékonyabban. A Microsoft va- 
rázslók segítségével könnyíti meg az áttérést a Windows 
2000 alapú DNS kiszolgálókra, ezek végigvezetnek a teljes 
folyamaton. Más DNS kiszolgálók is használhatók, de ebben 
az esetben több időt kell majd töltenünk a DNS adatbázisok 
kezelésével. Ha úgy döntünk, hogy nem Windows 2000 ala- 
pú DNS kiszolgálókat használunk, gondoskodnunk kell arról, 
hogy lehetőleg támogassák az új dinamikus DNS frissítés 
(DNS dynamic update vagy DDNS) protokollt. Az Active 
Directory kiszolgálók ezzel frissítik mutatórekordjaikat, a 
munkaállomások pedig ezen rekordok segítségével keresik 
meg a tartományvezérlőket. Ha a dinamikus frissítés nem tá- 
mogatott, akkor az adatbázist kézzel kell frissíteni. A DDNS 
protokollt a 2136-os RFC írja le. 

A Windows tartományok és az internetes tartományok mos- 
tantól teljesen fedik egymást. A tartománynevek (mint pél- 
dául a vallalat.hu) olyan Active Directory tartományvezér- 
lőket azonosítanak, melyek az adott tartományért felelő- 
sek, így bármely, DNS eléréssel rendelkező munkaállomás 
képes megtalálni egy adott tartományvezérlőt. Az Active 
Directory ügyfelek a DNS hozzárendelés segítségével bár- 
mely szolgáltatást képesek megtalálni, mert az Active 
Directory kiszolgálók - dinamikus frissítés használatával - 
bejegyzik önmagukat a DNS-be. Ezek a címek mind a tarto- 
mányt, mind a nyújtott szolgáltatást azonosítják, és szol- 
gáltatáserőforrás-rekordokon (Service Resource Record - 
SRV RR) keresztül kerülnek közzétételre. Az SRV RR-ek az 
alábbi formátumot követik: 


szolgáltatás .protokoll.tartomány 


Az Active Directory kiszolgálók LDAP protokollon keresztül 
teszik elérhetővé a címtárat, ezért ha egy kiszolgálót keres 
a vallalat.hu tartományban, akkor a DNS-rekordban az 
ldap.tcp.vallalat.hu rekordot fogja keresni. 


Az Active Directoryval kapcsolatos problémák 1109o- 
a a DNS-re, illetve a DNS ismeretének hiányára vezet- 
hetők vissza! 
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Replikáció 
Azok a rendszergazdák, akik Active Directory-t 
építenek, hamar észreveszik majd, hogy a háló- 


zat jelentős mértékben támaszkodik az Active PEYTTE ETT 


Directory szolgáltatásaira. Ez azt jelenti, hogy 

az Active Directorynak több kiszolgálón is el- 

érhetőnek kell lennie, így ha valamelyik meghi- 

básodik, a munkaállomások kapcsolatba tudnak 

lépni egy másik kiszolgálóval, melyen rendelkezés- 

re áll a szolgáltatások és az adatok másolata. A Win- 
dows NT korábbi verzióival használt Windows NT tarto- 
mányadatbázisoktól eltérően az adatbázis frissítései bár- 
melyik Active Directory kiszolgálónak elküldhetők. Bár ez a 
replikáció folyamatát bonyolultabbá teszi, annak az esélyét is 
kiküszöböli, hogy egy tartományvezérlő meghibásodása az 
adatbázist módosíthatatlanná tegye. Az új módszer a tarto- 
mányvezérlők terhelését is csökkenti. A replikáció folyamatá- 
nak megkezdéséhez elegendő egyszerűen hozzáadni a tarto- 
mányvezérlőket egy Active Directory tartományhoz. 

A redundáns kiszolgálók megfelelő működésében az egyik 
legbonyolultabb feladat az információk replikálása, illetve 
annak biztosítása, hogy minden kiszolgáló a legfrissebb 
tartalommal rendelkezzen. Az Active Directory többforrású 
(multimaster) replikációt alkalmaz, amely garantálja, hogy 
a frissítések minden Active Directory kiszolgálón megjelen- 
jenek. Minden kiszolgáló számon tartja, hogy melyik frissí- 
tést melyik kiszolgálótól kapta, és meghibásodás esetén 
intelligens módon csak azokat a frissítéseket kéri újra, 
amelyekre tényleg szüksége van. 


Az Active Directory replikáció működése 

Az Active Directory replikációja azok számára fog igazán lo- 
gikusnak tűnni, akik már ismerik a replikáció működését a 
Windows NT 4.0 tartományokban. Minden frissítés kap egy 64 
bites egyedi sorozatszámot (USN - Unigue Seguence 
Number), melynek értéke minden módosítás alkalmával nö- 
vekszik. Ezek a számlálók kiszolgálóspecifikusak, azaz minden 
Active Directory kiszolgáló saját számlálóval rendelkezik. 
Amikor egy kiszolgáló más Active Directory kiszolgálókra rep- 
likál egy frissítést, a módosítással együtt elküldi az USN-t is. 
Minden kiszolgáló rendelkezik egy belső listával, mely a rep- 
likációs partnereket, illetve az azoktól kapott legmagasabb 
USN értékeket tartja nyilván. A frissítést kapó kiszolgáló csak 
azokat a módosításokat kéri el, amelyeknek USN értéke ma- 
gasabb a korábban kapott értékeknél. Ennek a módszernek 
többek közt az az előnye, hogy meggátolja a frissítések vég 
nélküli keringését az Active Directory kiszolgálók között. 

A multimaster replikációs sémákban rejlő egyik probléma, hogy 
egyazon objektum frissítése egyszerre több helyen is megtörtén- 
het. Ha például egy rendszergazda Budapesten az egyik felhasz- 
nálónevet , Egerfalvi"-ról , Egérfalvi"-ra változtatja, és egy másik 
rendszergazda ugyanekkor Pécsett ugyanennek a felhasználónak a 
nevét , Egerfalvi"-ról , Égerfalvi"-ra, akkor replikációs ütközés lép 
fel, melyet automatikusan észlelni és javítani kell 

Az Active Directory ún. tulajdonságverzió-számokat tárol, 
melyek lehetővé teszik a replikációs ütközések felderítését. 
Ezek a számok az Active Directoryban szereplő minden ob- 





nehézségi fok. 
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jektum minden tulajdonságára nézve különbözőek, és min- 
den alkalommal frissülnek, amikor a tulajdonság módosul. 
Ezek a számok a változással együtt terjednek az Active 
Directory-n keresztül, így ha egy kiszolgálóhoz egyazon tu- 
lajdonság két különböző frissítése érkezik ugyanazzal a tu- 
lajdonságverzió számmal, akkor a kiszolgáló képes megálla- 
pítani, hogy replikációs ütközés történt. 

Az Active Directory kiszolgálók úgy oldják fel az ütközést, hogy 
a későbbi időbélyegzővel rendelkező frissítést alkalmazzák. Az 
időbélyegzőt a módosítást kezdeményező kiszolgáló hozza lét- 
re, ezért nagyon fontos, hogy a rendszeridő szinkronizálva le- 
gyen a Windows 2000 kiszolgálók között. A kiszolgálók órái- 
nak összehangolása a beépített SNTP időszinkronizáló szolgál- 
tatás segítségével automatikusan megvalósul! 


Partícionálás 

A nagy hálózatok több százezer objektumot tartalmazhatnak. 
A Windows NT esetében ilyen mennyiségű objektum kezelé- 
séhez több tartományra volt szükség. A felhasználókat és az 
erőforrásokat különálló tartományokra osztottuk, a tartomá- 
nyok közt pedig megbízotti kapcsolatokat hoztunk létre. Az 
adatbázisok szerkezete egyszerűen nem tette lehetővé, hogy 
az objektumok száma több százezerre növekedjen. Az Active 
Directory tartományokban a méretkorlátok szerencsére sokkal 
kevésbé számítanak. A nagyon nagy méretű Active Directory 
támogatása azonban egyetlen tartományvezérlőre hihetetlen 
mértékű terhet róhat. (Lásd előző számunkban a nagyméretű 
Ezen terhelés csökkentése érdekében az Active Directory partí- 
cionálható. A partícionálás lehetővé teszi, hogy a különböző 
tartományvezérlők az adatbázis különböző részeit kezeljék, így 
csökkentve az egyes kiszolgálókra jutó terhelést. A munkaállo- 
mások továbbra is egységesen használhatják a különböző Active 
Directory partíciókban elhelyezkedő erőforrásokat, így a rend- 
szergazdák anélkül képesek kezelni a nagy méretű Active 
Directory tartományokat, hogy a tartományvezérlőknek az 
egész adatbázist kezelniük kellene. 


Séma: attribútumok és objektumosztályok 

Ahogyan azt korábban már láttuk, a séma olyan attribútumok 
halmaza, amelyek egy adott objektumosztályt írnak le az 
Active Directoryban. A különböző objektumosztályok eseté- 
ben különböző adatok nyomon követésére van szükség, ezért 
olyan nagy a sémák jelentősége. A , felhasználók" objektum- 
osztály leírásához például a következő attribútumok szüksé- 
gesek: vezetéknév, utónév, telefonszám, elektronikus levél- 
cím és hagyományos levélcím. A ,nyomtatók" objektumosz- 
tály leírásához más attribútumok szükségesek: azt szeretnénk 
tudni, hogy az adott nyomtató mennyire gyors, vagy képes-e 
kétoldalasan, illetve színesben nyomtatni. Ezek az attribútu- 
mok az Active Directory Schema MMC beépülő modul segítsé- 
gével tekinthetők meg és szerkeszthetők. Az Active Directory 
Schema nem rendelkezik ikonnal a Start menüben. Tulajdon- 
képpen eléggé veszélyes dolog meggondolatlanul babrálni a 
sémát, mert nemcsak hogy az egész erdőben elterjednek a 
módosítások, hanem ráadásul visszavonhatatlanok is. Talán 
emiatt tüntették el a Start menüből, sőt, még a beépülő mo- 








dul sincs regisztrálva -— pedig ott csücsül a WINNTYSYSTEM32 
könyvtárban. Indításához először regisztrálni kell az MMC mo- 
dult (parancssorból adjuk ki a REGSVR32 SCHMMGMT.DLL paran- 
csot), majd el kell indítani az MMC felületet, és hozzá kell ad- 
ni az Active Directory Schema nevű modult. 
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Az Active Directory Schema segítségével módosíthatók az 
osztályok és az attribútumok 


Most pedig evezzünk veszélyesebb vizekre. Senkinek sem 
ajánlom azonban, hogy az éles, üzembe állított AD kiszolgá- 
lóján hajtsa végre a sémamódosítást, mert mint mondtam, 
a dolog végleges, visszavonhatatlan. Az objektumosztályok- 
hoz alapértelmezés szerint egy olyan logikai attribútumhal- 
maz tartozik, amely a legtöbb szervezet igényeinek megfe- 
lel. Azonban sok szervezetnek szüksége lesz arra, hogy bizo- 
nyos objektumokkal kapcsolatban további információkat kö- 
vessen nyomon. Ha például az alkalmazottak jelvényszám- 
mal rendelkeznek, érdemes lehet (ki tudja?) ezt az informá- 
ciót is felvenni az objektumosztályba. Első lépésként létre 
kell hozni egy JelvenyID nevű attribútumot, amint az az 
alábbi ábrán látható. Második lépésként az új attribútumot 
opcionálissá kell tenni a , felhasználók" osztály számára. 
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Create a New áttribute Object... 


Identification 
Common Name: JelvenyiD 
LDAP Display Name: JelvenyiD 


Unigue X500 Object ID: [1.2.840.3213.211.2.456 


Syntax and Range 

Syntax: Case Sensítive String gy 

Minimum: 

Maximurn: ! 
IT MultivValued Cancel 





Az Active Directory Schema beépülő modul segítségével új 
attribútumok vehetők fel. 
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A sémát az Active Directory úgy tárolja, mint bármely más 
objektumot. Így a séma örökli a tartományon keresztül tör- 
ténő automatikus replikálódás képességét, kihasználja az 
Active Directory biztonsági szolgáltatásait is, és lehetővé 
teszi, hogy séma fölötti jogköröket delegáljunk a különbö- 
ző felhasználóknak és csoportoknak. A sémaobjektumok 
ACL-einek (hozzáférés-szabályozási listáinak) módosítása 
révén a rendszergazdák bármely felhasználó számára lehe- 
tővé tehetik egy objektumosztály attribútumainak megvál- 
toztatását vagy bővítését. 

Az új attribútumok számos tulajdonsággal rendelkeznek, 
melyeket be kell állítani. Meg kell adnunk az attribútum ne- 
vét (például JelvényID), a tárolandó adat típusát (például 
karakterlánc vagy szám), illetve az értéktartományt (például 
a karakterlánc hosszúságát). Egyedi objektumazonosítót 
(0ID - Object Identifier) is meg kell adni (lásd később). Az 
új attribútumok indexelhetők, ekkor bekerülnek a globális 
katalógusba. Olyan attribútumokat érdemes indexelni, ame- 
lyekben a felhasználók keresni fognak. Az említett példánál 
maradva, ha a biztonsági szolgálat embereinek szüksége van 
arra, hogy a felhasználói fiókokat a jelvényazonosító számok 
alapján keressék meg, akkor ezt az attribútumot indexelni 
kell. Az index-szel nem rendelkező attribútumokban történő 
keresés lassú és processzorigényes feladat, melynek során az 
egész címtárfát be kell járni. 

Az osztályok és az attribútumok sem az Active Directory 
Schema sem más eszköz segítségével nem törölhetők. 
Létrehozásuk után örökké létezni fognak az Active 
Directoryban. Az egyetlen lehetőség az osztály deak- 
tiválása, amely megakadályozza annak további használatát. 
Nem deaktiválható olyan osztály vagy attribútum, amely 
függőséggel rendelkezik az Active Directory-ban. Ha példá- 
ul egy attribútumot még használ egy aktív osztály, akkor 
annak az attribútumnak aktívnak kell maradnia. 


Honnan származnak az objektumtípus azonosítók? 

Az objektumtípus azonosítók nem a GUID-k (amelyeket az 
Active Directory is képezni tud), hanem az X.500 szabvány- 
nak megfelelő, iparági besorolásszerű azonosítók (0ID) , me- 
lyekkel elkerülhető, hogy két cég azonos bővítményeket ké- 
szítsen az Active Directoryhoz, melyek azután nem lennének 
telepíthetők közös erdőbe. Az objektumtípus azonosítók 
globális egyedisége csak egy központi ügynökség segítségé- 
vel biztosítható, mely az azonosítók hozzárendeléséért fele- 
lős. Az Interneten ez már elterjedt gyakorlat: a tartomány- 
neveket az InterNIC, az IP-alhálózatokat pedig az Internet 
Assigned Numbers Authority (IANA) osztja ki. Objektumazo- 
nosítókat a National Registration Authority-tól (NRA) kér- 
hetünk. Az NRA minden országban más és más, az Amerikai 
Egyesült Államokban az NRA szolgáltatást az Amerikai Nem- 
zeti Szabványügyi Intézet (American National Standards 
Institute -— ANSI) látja el. Az ANSI csekély térítés ellenében 
bármely szervezet számára biztosít egy gyökér-OID-t. A szer- 
vezeten belül létrehozott valamennyi objektum megkapja 
ezt a gyökér-OID-t mint előtagot, így az objektumazonosí- 
tók globális egyedisége garantált. 

Az NRA-k listája a Nemzetközi Szabványügyi Szervezet 
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webhelyén a következő címen tekinthető meg: http: 
//www.iso.ch. Ugyanakkor ahhoz, hogy játszadozzunk a 
sémával, valószínűleg túl sok lenne egy fillér kifizetése is. 
OID nélkül viszont nem vehetünk fel újabb attribútumot. A 
kibúvó a Resource Kitben található OIDGEN.EXE, mellyel 
nagy valószínűséggel egyedi, sehol máshol nem létező 
0ID-ket lehet generálni. Ezek tökéletesen jók belső háló- 
zatunk bővítgetéséhez, de mint ahogy belső IP címekkel 
nem sokra megyünk a nyílt Interneten, ugyanígy hajítófát 
sem ér a random-OID akkor, ha eladásra készülő címtárter- 
mékben próbáljuk felhasználni. 

Az Active Directory sémájának kiterjesztése igen hatékony 
lehetőség, bár a Microsoft által biztosított alapértelmezé- 
seken felül a legtöbb rendszergazdának soha nem lesz 
szüksége más osztályok és attribútumok használatára. 


Objektumok 

Az első pillanatban sokakat zavarba ejt az objektumosztá- 
lyok, attribútumok és az objektumok kapcsolata. Az objektu- 
mok egy objektumosztály alapján jönnek létre. Az attribútu- 
mok egy-egy objektumosztályt írnak le. Egy objektum létre- 
hozásakor az objektum örökli objektumosztályának vala- 
mennyi attribútumát. A dolog megértését a következő tény 
nehezíti: az objektumosztályok és az attribútumok maguk 
is objektumok az Active Directoryban. Ezt a tényt szeren- 
csére a legtöbb felhasználói felület elrejti. 

Egy objektum lehet egy konkrét dologra utaló hivatkozás, 
vagy maga a tényleges információ. Például a felhasználói 
fiókokkal kapcsolatos valamennyi információ az Active 
Directory-ban van tárolva. Ugyanakkor az Active Directory 
a lemezkötetekkel kapcsolatban csupán egy hivatkozást tá- 
rol. Bár a hivatkozás önmagában nem hasznos információ, 
mégis felhasználható a kötetek megkeresésére a fájlkiszol- 
gálón. Új objektumosztályok létrehozásakor alaposan át 
kell gondolni, hogy az objektum vajon egy külső dologra 
utaló hivatkozást fog-e tárolni, vagy az objektum attribú- 
tumai tartalmazni fogják-e az összes fontos információt. 
Bár az Active Directory rendkívül kényelmes eszköz, nem 
szabad nagy mennyiségű állandóan változó vagy ritkán 
használt információ tárolására használni. 

Amikor valaki új felhasználót vagy számítógépet ad az Active 
Directory-hoz, tulajdonképpen egy objektumot hoz létre. Az 
objektumok létrehozását gyakran közzétételnek is nevezzük, 
mert az objektum létrehozása replikációs folyamatot indít el, 
amelyben az új információ replikálódni kezd a tartományban 
található összes Active Directory kiszolgálóra. 


Szabványos objektumosztályok 

A Windows 2000 Server az Active Directory segítségével tá- 
rolja a felhasználókra, csoportokra és számítógépfiókokra vo- 
natkozó nagy mennyiségű adatot. Ezek az adatok különösen 
a rendszergazdák számára fontosak, mert ezek képezik az 
Active Directory leggyakrabban elért részét. A korábban Win- 
dows NT környezetben dolgozó rendszergazdák számára az új 
felhasználói felület esetleg nem tűnik túl intuitívnek, de rö- 
vid idő eltelté után a kezelése egészen egyszerűvé válik. 
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Felhasználók 

A felhasználói fiókok kezelése többé nem egy különálló esz- 
köz segítségével történik, hanem az Active Directory Users 
and Computers MMC beépülő modult használjuk. Maguk a 
felhasználói fiókok is jelentősen megváltoztak. A Windows 
NT 4.0 csupán a felhasználói nevet, a teljes nevet, a leírást, 
a jelszót és néhány egyéb attribútumot tartott nyilván. A 
Windows 2000 Server rendszerben a címtárnak köszönhető- 
en ezek az attribútumok kiterjeszthetők. Az Active Directory 
segítségével számtalan személyes adat nyilvántartható, be- 
leértve a telefonszámokat, a lakcímeket és a felettesek ne- 
veit. Ezek a kiegészítő információk teljesen opcionálisak. 
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állításaiban, vagy működhet egyszerű terjesztési listaként. 
A Windows 2000 Server számos alapértelmezett csoportot 
tartalmaz, ezeket beépített csoportoknak nevezzük, és 
igény szerint további csoportokat vehetünk fel. 
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Az Active Directory Users and Computers beépülő MMC 
modul felváltja a Felhasználókezelőt 


Csoportok 

Az Active Directory csoportok a Windows NT korábbi verziói- 
ban megszokott felhasználói csoportokhoz hasonlóak, azon- 
ban számos új szolgáltatással rendelkeznek. A Microsoft 
Exchange legújabb verziója lehetővé teszi a csoportok elekt- 
ronikus levelezési (terjesztési) listákként történő használatát. 
Hogy a szolgáltatás még hasznosabb legyen, a csoportokhoz 
elektronikus levelezési fiókok is hozzáadhatók, így a terjesz- 
tés azon felhasználók felé is lehetővé válik, akik nem tagjai 
ugyanannak az Active Directory fának. A csoportok egymásba 
is ágyazhatók, így a rendszergazdáknak lényegesen kevesebb 
időt kell tölteniük a felhasználók és a csoportok kezelésével. 
Mostantól három különféle csoport létezik. Az univerzális 
csoport a legrugalmasabb típus, az erdő tetszőleges felhasz- 
nálóját vagy csoportját tartalmazhatja. Ezek a csoportok a 
tartományon kívül is replikálódnak, és megjelennek a globá- 
lis katalógusban. A globális csoportok csak saját tartomá- 
nyukból fogadhatnak be felhasználókat és csoportokat. A 
globális csoportok szerepelnek ugyan a globális katalógus- 
ban, de tagsági listájuk már nem. A tartományszintű helyi 
csoportok csak egyazon tartományban található hozzáférés- 
szabályozási listákra (ACL) alkalmazhatók, de más tartomá- 
nyokba tartozó felhasználókat és csoportokat is tartalmaz- 
hatnak. Ezek nem replikálódnak a tartományon kívül, és 
nem jelennek meg a globális katalógusban. A három cso- 
porttípus mindegyike részt vehet a tartomány biztonsági be- 
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A MICROSOFT MAGYARORSZÁG 


A Windows 2000 Server számos beépített csoportot 
tartalmaz 


9 ( ForeignseauityPrincipals EEJMarcel Pannon. Foti Contact Marcell F 
téka Messan E "0[ Szártágérűtékek 
; tek Ez] mieképelender.hu Övék A tartományhoz csatlakozó számítógépek automatikusan 
7 (52) Ujsagírok keze SESZÉÉSÉS e [mos [  számítógépfiókot kapnak az Active Directoryban. Ez a fo- 
Ne £€2 Tibor Adorján User lyamat ahhoz hasonlít, mint amikor egy új gépet adunk a 
8 ueag re Windows NT 4.0 tartományhoz. Azonban a gépeket akkor is 
saj ájl a tartományhoz lehet adni, ha azok nem vesznek részt a 


tartományvédelemben. (Például létrehozhatunk egy számí- 
tógép-objektumot egy UNIX rendszer számára is.) 


Lightweight Directory Access Protocol (LDAP) 

Az Active Directory tükrözi a Microsoft azon célkitűzését, 
hogy a rendszerek minél inkább támaszkodjanak a szabvá- 
nyos protokollokra. A Lightweight Directory Access Protocol 
(LDAP) az IETF (Internet Engineering Task Force) szabványa. 
A protokoll a munkaállomások és kiszolgálók címtárakkal 
kapcsolatos információcseréjét definiálja. A Windows 2000 
Active Directory az LDAP 2-es és 3-as verzióját használja. 


Egyszerű felhasználónév 

Az LDAP megkülönböztető nevek a számítógépek számára ki- 
válóak, de a felhasználók nehezen jegyzik meg őket. Mivel 
már hozzászoktunk az elektronikus levélcímekhez, ezért az 
Active Directoryban ezeket a címeket a teljes objektumnévre 
mutató hivatkozásként használhatjuk. Az én bejelentkezési 
nevem például marcellf(onetacademia.net. 

A felhasználók egyszerű felhasználónevük segítségével je- 
lentkezhetnek be a Windows 2000 rendszerbe. Az emailszerű 
nevek felváltják a régebbi Windows hálózatokban használt 
felhasználóneveket, így a felhasználóknak nem kell teljes 
LDAP nevüket begépelniük. Az egyszerű felhasználónevek to- 
vábbi előnye, hogy akkor sem változnak meg, ha a rendszer- 
gazda áthelyezi vagy átnevezi az adott felhasználói fiókot. 
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ADSI (Active Directory Service Interface) 

Az ADSI (Active Directory Service Interface) lehetővé teszi, 
hogy az alkalmazások anélkül lépjenek kölcsönhatásba bár- 
mely címtárszolgáltatással, hogy ismerniük kellene a meg- 
felelő protokollok belső szerkezetét. A fejlesztők olyan 
programokat és parancsfájlokat írhatnak, amelyek az ADSI- 
t kihasználva írják és olvassák az örökölt Windows NT 4.0 
címtárakat, NetWare NDS címtárakat, NetWare 3 binderyket 
és az LDAP címtárakat (pl. Active Directory). Akár anélkül 
is létrehozhatunk olyan alkalmazásokat, amelyek kihasz- 
nálják a meglévő címtárakat, hogy előzetesen ismernénk a 
használt címtár típusát. (Erről a témáról pedig e számunk 
fejlesztői rovatában olvashatnak — a szerk.) 


Hálózattervezés az Active Directory-hoz 

A munkaállomások a telephely-információk segítségével 
azonosítják a legközelebbi Active Directory kiszolgálót. Mi- 
vel a telephelyek IP-alhálózatoknak felelnek meg, minden 
alhálózaton el kell helyezni egy Active Directory kiszolgá- 
lót. Arról is gondoskodni kell, hogy az egyazon logikai al- 
hálózaton található valamennyi rendszer a helyi hálózaton 
keresztül csatlakozzon. Bizonyos útválasztási technológiák 
- mint például a Proxy Address Resolution Protocol (Proxy- 
ARP) - lehetővé teszik, hogy az ugyanazon logikai alháló- 
zaton található rendszerek a hálózat különböző fizikai szeg- 
mensein helyezkedjenek el. Ennek a beállításnak a hatásá- 
ra az ügyfelek egymáshoz közelebbinek érzékelik az egyes 
rendszereket, mint a valóságos helyzet, ezért érdemes a 
szabványos útválasztási technológiákhoz ragaszkodni. Ha 
az olvasónak mindez nem sokat mond, akkor minden rend- 
ben van: hálózata valószínűleg megfelelően van beállítva. 

A hálózat átállítása előtt meg kell tervezni az Active Directory 
szerkezetét. Erre két lehetőség nyílik: létrehozhatunk egy új 
fát, vagy csatlakozhatunk egy létező fához. Az átállítani kí- 
vánt hálózat első tartománya esetében nyilvánvalóan új fát 
kell létrehozni. Ha azonban a rendszergazda több tartományt 
szeretne egyesíteni egyetlen Active Directory tartományban, 
akkor a létező fa gyermekeként kell csatlakoznia. 

Az áttérést mindig a Windows NT 3.51 vagy 4.0 PDC-vel 
(Primary Domain Contorller - Elsődleges tartományvezérlő) 
kell kezdeni. Az aktuális tartomány felhasználói és csoport- 
jai automatikusan átkerülnek az Active Directory-ba, a léte- 
ző ügyfelek pedig pontosan úgy fognak kapcsolódni az új tar- 
tományvezérlőhöz, mintha az még mindig PDC lenne. Amíg 
az Active Directory kiszolgálók, és az örökölt BDC-k (tartalék 
tartományvezérlők) párhuzamosan működnek, a tartomány 
vegyes üzemmódban fog működni, amint az alábbi ábráról 
leolvasható. A vegyes tartományok nem tudják maradéktala- 
nul kihasználni az Active Directory új szolgáltatásait, mert az 
Active Directorynak biztosítania kell a lefelé irányuló kompa- 
tibilitást. Vegyes üzemmódú tartományokban például nem 
használhatók egymásba ágyazott csoportok. 
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General ] Managed By ] Object] Security] Group Poop] 










"Mixed mode (supports both Windows 2000 and pre:windows 2000 domain 
controllers) 


Domain mod ————————————————— 


AN To change the domain to native mode, cick Change Mode. J 
This opetation cannot be reversed. For more information about 
domain modes, see Help. 

I 
I 


Örökölt BDC-k létezésekor vegyes üzemmódú tartomá- 
nyok működnek. 


Ha a rendszergazda meggyőződött arról, hogy a vegyes 
üzemmódú tartományok tökéletesen működnek, végre kell 
zérlő átállítása megtörtént, a tartomány natív üzemmódba 
kapcsolható, és kihasználható az összes új szolgáltatás. A 
tagkiszolgálók és a munkaállomások támogatása teljes körű, 
nincs szükség semmilyen módosításra, vagy beavatkozásra az 
Active Directory kiszolgálókkal történő együttműködés bizto- 
sításához. A tagkiszolgálók frissítése további előnyökkel jár, 
de először mindig a tartományvezérlőket kell frissíteni. 

A Windows NT Workstation munkaállomások csak akkor 
tudják kihasználni az Active Directory új szolgáltatásait, 
ha azokat Windows 2000 Professional rendszerre frissítik. 
A Windows 95 és Windows 98 ügyfelekhez javítócsomag 
készült, melynek telepítése után ezek is képesek lesznek 
érzékelni az Active Directoryt, és részt tudnak venni a 
Kerberos adatvédelemben. 


Összefoglalás 

A hálózatot leginkább az Active Directory bevezetése mi- 
att érdemes frissíteni. Az Active Directory a Windows NT 
tartományokat egyesíti az internetes tartományokkal, és 
lehetővé teszi azok vállalati szintű kiterjesztését. Bár a 
legjelentősebb előny a csökkentett üzemeltetési költség, a 
felhasználók a globális katalógus továbbfejlesztett kereső- 
lehetőségei révén közvetlen előnyökhöz is jutnak. 

A Microsoft szándéka az, hogy az Active Directoryra törté- 
nő áttérés a lehető legegyszerűbb legyen. Varázslók állnak 
rendelkezésre, melyek segítségével a DNS-feladatok átad- 
hatók a Microsoft DDNS (Microsoft DNS dynamic update) ki- 
szolgálóknak. A felhasználók és a csoportok automatikusan 
importálódnak az örökölt Windows NT tartományokból. Vé- 
gezetül az Active Directory telepítésének minden mozzana- 
ta intuitív, továbbá minden összetett feladat automatikus. 
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Microsoft SOL Server 2000 Transact SOL - 1. rész 
Egyszerű lekérdezések 


9. Bevezetés 
§ Az SOL Server 2000 a 2000. évi adatbázispiac 
leghangosabban debütáló terméke. A konku- 
rencia is árgus szemekkel figyeli mit tud az új 
termék, és igyekszik, hogy elvegye tőle a leg- 
gyorsabb adatbáziskiszolgálónak járó díjat. 
Nem véletlenül! Már az SOL Server 7 is nagyon ki- 
finomult és hatékony relációs adatbáziskezelő volt, 
azonban az utód még igen sok és rendkívül érdekes szol- 
gáltatással rukkolt elő. Ezek kiaknázásához azonban elen- 
gedhetetlen a Transact SOL ismerete. 
A Transact SOL egy nagyon bonyolult dolog. Legalábbis leg- 
többen ezzel nyugtatják magukat, amiért nem tanulják 
meg. Ebben a cikksorozatban rácáfolok erre az állításra. Na- 
gyon kifinomult nyelv, azonban egyszerűbb lekérdezéseket és 
adatmódosító scripteket bárki képes lesz írni, amint elolvasta 
és végiggyakorolta ezt a cikksorozatot. Vágjunk hát bele! 


Előkészületek 

Adott az SOL 2000 Server-ünk. Van rajta egy Northwind ne- 
vű adatbázis, ami a szerencséseknek a kiszolgálóval együtt 
települt fel. (Aki kevésbé az, az futtassa le az instnwnd.sgl 
scriptet a Program Files Microsoft SOL ServertUnstall mappá- 
ból. Ez létrehozza az adatbázist, és feltölti adatokkal.) Az 
adatbázis a Northwind Traders nevű ételkereskedelemmel 
foglalkozó cég ügyfeleit, eladásait és sok egyéb céges ada- 
tát rögzíti. Van benne egy Customers tábla, ami a cég ügy- 
feleit tartja nyilván, egy Products tábla, ami a kínált termé- 
keket, egy Orders tábla, ami a megrendeléseket, egy 
Employees, ami az alkalmazottakat. Ezeken kívül van még 
sok egyéb tábla is benne, de az egyszerűség kedvéért most 
csak ezeket fogjuk használni. 

Adjuk ki az első SOL parancsunkat! Nyissuk meg a Ouery 
Analyzer nevű programot a Start Menu/Microsoft SOL Server 
alatt. Ez egyike azon alkalmazásoknak, amelyet nagyon szere- 
tünk használni. Ahogyan a Windows 2000 parancsokat a pa- 
rancssorban próbálhatjuk ki, hasonló módon a Ouery Analyzer 
segítségével lehet tesztelni az SOL lekérdezéseinket. 

Elindult a program, és kérdezi, hogy melyik kiszolgálóra sze- 
retnénk csatlakozni. Írjuk be a gépünk nevét. Ha a lokális gé- 
pen van, akkor írjunk (local)-t. Ha mi vagyunk a nagyfiúk a 
gépen (administrator), akkor használjunk Windows NT 
authentication-t. Ha nem, akkor használjunk SOL authenti- 
cation-t, sa Login nevet és a megfelelő, leggyakrabban üres 
jelszót. (Éles környezetben nem árt ám adni neki egy jelszót! 
Az esetek igen jelentős részében elfeledkeznek erről, és később 
csodálkoznak, hogy az SOL Servert is futtató webkiszolgá- 
lónkon reggelre kicserélték a főoldalt. Az sa login-nal az SOL 
Serverre belépve ugyanis kb. 30 mp. alatt rendszergazdává vál- 
hat bárki.) Akik több SOL Servert is futtatnak ugyanazon a 
gépen, a gépnévpéldány nevet írják be a név mezőbe. 


Bemelegítés 

Sikerült csatlakozni? Akkor a nehezén már túl vagyunk. A 
Toolbar közepén van egy legördülő lista, ott válasszuk ki a 
Northwind adatbázist, jelezve, hogy SOL parancsainkat ab- 
ban szeretnénk végrehajtani. Adjunk a gépnek végre mun- 
kát! Kérjük meg, hogy szíveskedjen kilistázni a cég összes 
vásárlójának a nevét. Ez SOL-ül valahogy így néz ki: 


(ES a ee zel em gáton el ze ezét 
SOL Server 2000 Transact SOL 


SELECT 
CompanyName 

FROM 
Customers 


Írjuk be a parancsot a Ouery ablakba, majd nyomjunk F5-öt 
a futtatáshoz. Felszállt a mérőfüst? Ha minden rendben 
ment, akkor az alsó ablakban 91 céget láthatunk a világ 
minden részéről, élen a közismert Alfreds Futterkiste céggel: 


Alfreds Futterkiste 
Ana Trujillo Emparedados y helados 
Antonio Moreno Taguería 


Hogyan fordíthatnánk le magyarra az előbbi SOL parancsot? 
Hát körülbelül úgy, mintha angolról fordítanánk. Válaszd ki a 
cégnevet a Customers táblából. Ez a szépsége az SOL nyelv- 
nek, hogy nem For, Loop és egyéb csúfságokkal kell bíbelőd- 
ni, hanem majdnem angolul megfogalmazzuk a kérésünket, 
és az SOL Server végrehajtja azt. A SELECT kulcsszó után 
megadjuk azoknak az oszlopoknak a nevét, amelyeket szeret- 
nénk látni a parancs kimeneteként, a FROM után pedig azok- 
nak a tábláknak a nevét, ahonnan származnak az adatok. Eb- 
ben a példában csak egy forrástáblánk volt. 

Néhány gondolat a parancsok tagolásáról. Mint minden 
programozási nyelvben, sokféle tagolási lehetőség kínálko- 
zik a számunkra (C programozók szoktak vérre menően har- 
colni a kapcsos zárójelek helyéről). Az SOL parancsok akkor 
lesznek a legolvashatóbbak, ha minden kulcsszót külön sor- 
ba írunk, azaz a SELECT is kap egy saját sort, a WHERE is és 
a többiek is. A kulcsszavakhoz kapcsolódó egyéb paraméte- 
reket is célszerű új sorba írni, valamelyest beljebb tolva. A 
cikk további részében ehhez a konvencióhoz tartom magam. 


Feltételek, és ahol a problémák kezdődnek: a NULL 
Fűszerezzük meg a példánkat! Válogassuk le csak a német 
vásárlókat, azaz akiknek a Country mezőjében Germany áll. 
Mi sem egyszerűbb: 


SELECT 
kk 
FROM 
Customers 
WHERE 
Country - "Germany" 
ALFKI Alfreds Futterkiste Maria Anders 
Sales Representative Obere Str. 57 
Berlin NULL 12209 Germany 
030-0074321 030-0076545 


BLAUS Blauer See Delikatessen Hanna 
Moos Sales Representative 

Forsterstr. 57 Mannheim NULL 
68306 Germany 0621-08460 0621- 
08924 

DRACD Drachenblut Delikatessen Sven 


Order Administrator 
52066 
0241-059428 


ottlieb 
Walserweg 21Aachen NULL 
Germany 0241-039123 
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Hogy került oda az a csillag? Ez a lusta SOL programozók 
egyik legnagyobb öröme (és a Ouery Optimizer egyik legna- 
gyobb bánata). Ha nem akarunk minden oszlopot kézzel 
felsorolni a SELECT után, akkor használhatjuk a csillagot, 
ami kilistáz minden oszlopot. Csak bánjunk vele csínján! 
Gyorsak ugyan a mai számítógépek, de amikor tízezres 
nagyságrendű sorok mellett egyenként is kilobájtos mére- 
tű sorokat válogatunk le, hát bizony bámulhatjuk a ho- 
mokórát, vagy az időtúllépésről szóló hibaüzeneteket, nem 
is beszélve a haragos ügyfélről. 

A WHERE záradék után megadott logikai feltételekkel szű- 
kíthetjük a listázás eredményhalmazát (Result Set). Mi 
csak azokat a sorokat listáztuk, amelyekben a Country att- 
ribútum (oszlop) értéke megegyezik a , Germany" szöveg- 
gel. Itt tetszőlegesen bonyolult logikai kifejezések állhat- 
nak, csak igyekezzünk jól tagolni, hogy pár hónap múlva is 
olvasható és érthető legyen a korábban zseniálisnak kiki- 
áltott feltételünk. Például: 


SELECT 
CompanyName , 
FROM 
Customers 
WHERE 
Country - "Germany" AND 
Fax IS NULL 


Country, Fax 


Königlich Essen Germany NULL 
Morgenstern Ge... Germany NULL 
OUICK-Stop Germany NULL 


Azaz kérünk minden olyan sort, ahol a cégnév Germany, és 
a Fax mező értéke NULL. De mi az a NULL? Ezt a kérdést 
sokszor többéves tapasztalattal rendelkező SOL programo- 
zók sem tudják, pedig igen lényeges a tisztánlátás az ő tu- 
lajdonságait illetően. 

A NULL egy SOL adatbázisban azt jelenti, hogy nincs adat. 
Nem keverendő össze a 0 számmal, vagy az ,," üres sztring- 
gel, még kevésbé a NULL pointerrel! Majd az illesztéseknél 
(JOIN) látjuk, hogy igen sok problémát okozhatnak, úgy- 
hogy szemmel kell tartani őket. Látható, hogy az összeha- 
sonlító operátor (is) más, mint amit egyéb, , normális" 
adatra alkalmazunk (z, c, - stb.). A nyelv szerzői ezzel is 
meg akarták különböztetni a NULL-t a valós adatoktól. 
Hisz 2 5 NULL az igaz? Hmm. A jó ég tudja. Pont ezért 
problémás a NULL adatok kezelése, mert amíg normális 
adatokra megfelelően működnek az operátorok, NULL-ra 
nem. Ez nem jelenti azt, hogy hibát jeleznek, vagy vélet- 
lenszerűen viselkednek. Természetesen következetes mó- 
don fognak viselkedni, csak meg kell nézni a kézikönyv- 
ben, hogy milyen feltételek esetén milyen eredményt ad- 
nak, vagy ami ennél százszor jobb megoldás: ahol csak le- 
het, kerüljük el a NULL-okat. Ínyenceknek: a Microsoft SOL 
Server fizikai adattárolási struktúrája olyan, hogy minden 
egyes NULL engedélyezett attribútumhoz van egy jelzőbit, 
amely jelzi, hogy tartalmaz-e a mező tényleges adatot, 
vagy nem (azaz NULL). Ez a sort leíró fejlécben van, hisz 
ezt minden sor minden NULL-ozható attribútumára tárolni 
kell. Azaz ez a plusz adminisztráció még egy kis teljesít- 
ményhátrányt is jelent. 





Csak számolunk, csak számolunk 

Hagyjuk a ronda NULL-okat, és haladjunk tovább a normá- 
lis adatok világában. Mi van, ha a big boss abc sorrendben 
szeretné látni az amerikai megrendelőket? 


SELECT 
CompanyName 
FROM 
Customers 
WHERE 
Country -— 
ORDER BY 
CompanyName 


"USA" 


Great Lakes Food Market 
Hungry Coyote Import Store 
Lazy K Kountry Store 
Let"s Stop N Shop 


F5, és nagy az öröm. Az ORDER BY után több mezőt is fel 
lehet sorolni, azaz, hogy először az első mező szerint ren- 
dezzen sorba, majd ezeken a csoportokon belül rendezze 
tovább a második, stb. attribútum szerint. A rendező me- 
zőnevek közé vesszőt kell rakni, hasonlóan, mint a SELECT 
után. Pl.: 


SELECT 
Country, 
ContactName 
FROM 
Customers 
ORDER BY 
Country, 


City, CompanyName, 


City, CompanyName 


A főnök kíváncsisága csillapíthatatlan. Kíváncsi rá, hogy 
meddig ér a lepedője, azaz mely országokkal van kapcsola- 
ta a cégének. Ám legyen: 


SELECT DISTINCT 
Country 

FROM 
Customers 


Argentina 
Austria 
Belgium 
Brazil 


Mit is mondtunk az SOL Server-nek? Listázza ki az összes 
különböző (DISTINCT) országot a Customers táblából Ez 
olyan egyszerű SOL-ben, mint ahogyan látszik! Aki hozzá- 
szokott a procedurális gondolkodáshoz, annak szokatlan ez 
a fajta gondolkodásmód, ahogyan SOL nyelven definiáljuk 
a problémákat. Egy procedurális nyelven (C, Pascal, Basic 
stb.) úgy válogatnánk le a sorokat, hogy végigmennénk 
minden soron, egybegyűjtenénk a már megtalált országo- 
kat, és minden egyes még feldolgozatlan sornál megnéz- 
nénk, hogy már benne van-e az adott tétel a megtaláltak 
között. Ha nem, felvesszük, ha igen, akkor csak egyszerű- 
en továbblépünk a következőre. Azaz procedurális esetben 
sorokban, egyedi adatokban gondolkodunk, míg a másik 
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esetben halmazokban. Több év C által megfertőzött szek- 
venciális gondolkodás után szokatlan lehet ez, de könynyen 
meg lehet szokni, és miután valaki ráérzett az ízére, rájön, 
hogy ilyen módon sokkal egyszerűbben és tömörebben 
meg lehet fogalmazni a problémákat (nem véletlen, hogy 
ily módon fejlesztették ki az SOL nyelvet). Másrészt kurzo- 
rok használatában át lehet térni szekvenciális feldolgozás- 
ra, de erről majd egy teljes cikk fog szólni. 

Na, de félre az ideológiákkal, számoljuk meg, hány ügyfe- 
lünk van Franciaországban: 


SELECT 
COUNT ( 7) 
FROM 
Customers 
WHERE 
Country - "France" 
11 


Magyarul: számoljuk meg az összes sort, ahol az ország 
oszlopban Franciaország áll. A COUNT az aggregáló függvé- 
nyek egyik jeles képviselője. Ezeknek a függvényeknek az 
a közös jellemzőjük, hogy több sorból képeznek valamilyen 
végeredményt, a sorok valamelyik attribútumát felhasznál- 
va. Ebből a szempontból a COUNT(") egy kicsit speciális, 
mert az oszlopoktól függetlenül egyszerűen megszámolja a 
sorokat. Egy újabb példán keresztül nézzünk egy kicsit mö- 
gé a COUNT függvénynek. 

Hány cégnek van faxa, vagy legalábbis úgy tudjuk róla, 
hogy van neki (azaz a Fax mező nem NULL)? 

Klasszikus megoldás: 


SELECT 
COUNT(") 
FROM 
Customers 
WHERE 
Fax IS NOT NULL 


69 
Microsoft SOL Server specifikus, de jól működő megoldás: 


SELECT 
COUNT (Fax) 

FROM 
Customers 


69 


Miért működik ez jól? Miért nem számolja meg az összes sort, 
miért csak azokat, amelyekben a Fax mező nem NULL? Mert 
így logikus. Mivel a NULL azt jelenti, hogy nincs adat, vagy 
nem tudunk róla semmit, ezért nem is szabad belevenni az 
ilyen számlálásokba. Ez megint csak a NULL értékek sajátos- 
sága (mondtam, hogy sok baj van a NULL-okkal). Az összes 
aggregáló függvény bokorugrásban megy tovább a követke- 
ző sorra, ha a feldolgozás alatt álló mezőben NULL van. Hisz 
mit kezdene egy átlagszámító függvény a NULL-lal? 

A COUNT(?) azért lóg ki a sorból, mert minden sort beszá- 
mol, még akkor is, ha minden attribútum értéke NULL. A 
két megoldás egyformán hatékony, de míg az előbbi jól ol- 
vasható és nem tartalmaz implicit megállapodásokat, ad- 
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dig a második néhány hónappal a fejlesztés után már fej- 
törést okozhat, hogy mi a csudát akartam én kezdeni azzal 
a kifejezéssel. Azaz nem javaslom a második megoldást. Aki 
úgy érzi, hogy a második megoldás gyorsabb, annak elmon- 
dom, hogy az SOL Server esetén szintaktikai bravúrokkal ál- 
talában nem sikerül teljesítményt javítani, mert úgyis azzal 
kezdi az utasítások végrehajtását, hogy lebontja őket elemi 
részekre, és az (általa vélt) legoptimálisabb módon fogja 
végrehajtani. Eddig még legtöbbször okosabb volt nálam :) 
Maradjunk még egy kicsit az aggregáló függvényeknél! To- 
vábbi tipikus példák a MIN, a MAX és az AVG és a SUM. Az 
első kettő egyértelmű, az AVG számtani közepet (népi nyel- 
ven átlag) számol, a SUM pedig összeadja a megadott me- 
zőket. Nézzünk egy példát, amiben felhasználjuk mind- 
egyiket! Keressük meg a legkisebb és a legnagyobb egy- 
ségárú termék árát, az egységárak átlagát és az egységárak 
összegét az összes termékre vonatkozóan. 





SELECT 
MIN(UnitPrice) , 
MAX (UnitPrice) , 
AVG(UnitPrice) , 
SUM(UnitPrice) 

FROM 
Products 

2.5000 263.5000 28.8663 2222.7100 

Veszedelmes viszonyok 

Vegyünk nagy levegőt, és mélyedjünk el egy kicsit az adat- 

báziskezelés elméletébe. Miért mondják az SOL Serverre, 

hogy relációs adatbáziskezelő? Azért, mert a benne levő en- 
titások (ennek magyar megfelelője az izé, de fizikai adatbá- 
zisban táblának felel meg) között logikai kapcsolatokat, re- 
lációkat fogalmazhatunk meg. Ezt azért találták ki, mert így 
az ismétlődő adatokat kiemelhetjük külön táblákba, egy- 
részt helyet spórolva meg, másrészt az adatbázis konzisz- 
tenciájának biztosítása végett. Lássunk erre egy példát. Az 

Orders tábla tárolja az ügyfelek vásárlásait. Azonban min- 

den egyes sorban az ügyfelet csak egy azonosító jelzi (pl.: 

RATTC), amely azonosító alatt futó ügyfél valódi adatai a 

Customers táblában vannak. Ezzel helyet spóroltak, hisz 

nem kell többször leírni az ügyfél címét, nevét stb. minden 

egyes megrendelésnél, másrészt nem fogunk találni olyan 
sorokat, hogy megrendelő Egér Béla, a másikban, hogy Eger 

Bela és így tovább. Így az adatbázis logikailag konzisztens 

marad, hisz ugyanarra a valóságos egyedpéldányra (Éger 

Béla) nem hivatkozhatunk többféleképpen. Egyébként azt a 

folyamatot, amikor a redundáns részeket kirakjuk külön 

táblába, normalizálásnak nevezzük. Ebből következően azok 
az adatbázisok normálisak, amelyekben sok, de keskeny, 
azaz kevés oszlopot tartalmazó tábla van. Az elméleti ma- 
ximumig agyonnormalizált adatbázist azonban keveset lá- 
tunk a világban. Ennek két oka van. Egyrészt sokan nem is 
tudják, hogyan kell normalizálni (és hogy egyáltalán kell), 
másrészt teljesítménymeggondolások miatt sokszor norma- 
lizálás után denormalizáljuk valamelyest az adatbázisunkat. 

Egy nem megfelelően normalizált adatbázissal az a baj, 

hogy nehéz a konzisztenciáját megtartani. Például egy osz- 

lopban tároljuk egy termék árát, egy másikban az ÁFÁ-ját, 
egy harmadikban pedig az ÁFA-s árat. Ez gyönyörű példája 

a NEM normalizált adatbázisnak (triviális függőség van az 

oszlopok között). A baj akkor kezdődik, amikor megváltozik 

a termék ára, és elfelejtjük módosítani az ÁFA-s árat. Egy 
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hét (perc) múlva, amikor már senki nem emlékszik, melyik 
mező volt módosítva, melyik árat fogadjuk el helyesnek? 
Újra együtt! 

Vissza a gyakorlatba, hogyan lehet összehozni a szétdara- 
bolt információkat? Ehhez lesz szükségünk a JOIN kulcs- 
szóra. Listázzuk ki a megrendelők által kért megrendelések 
dátumát és a szállítás városát: 


SELECT 

CompanyName, OrderDate, ShipCity 
FROM 

Customers 
INNER JOIN 

Orders 
ON 

Customers.CustomerID — 
Orders . CustomerID 


CompanyName OrderDate ShipCity 

Vins et alcools Chevalier 1996-07-04 
Reims 

Toms Spezialitáten 1996-07-O5 Münster 
Hanari Carnes 1996-07-O8 Rio de Janeiro 


Azaz a Customers táblát illessze az Orders táblához, még- 
pedig azokon a pontokon, ahol a Customers tábla 
CustomerID mezője megegyezik az Orders tábla CustomerID 
mezőjével. Minden egyes egyezésnél készít egy ,hosszú" 
sort, azaz egymás mellé rakja a két tábla összeillesztett s0- 
rát, amelyekből mi csak a SELECT után felsorolt oszlopokat 
kérjük. SOL Server 6.5-ig ez úgy ment, hogy vette az első 
tábla első sorát, és megnézte, hogy az ON után megadott 
feltétel alkalmazásával a másik táblában talál-e egy párt a 
vizsgált sornak. Ha igen, akkor egymás mellé illesztette 
őket, letárolta, és folytatta a második tábla következő so- 
rával, hisz általában több sor is illeszkedhet a vizsgált sor- 
hoz. Ez első ránézésre hihetetlen lassú folyamat, hisz, a két 
tábla sorai számának szorzata adja az összehasonító műve- 
letek számát. Az indexek használata miatt ez szerencsére 
nem így van. Ennek az illesztési eljárásnak a (jól eltalált) 
neve Nested Loop Join. SOL 7-től még két további illesztő 
algoritmus áll rendelkezésre, amelyeket nagyon sok sort adó 
lekérdezéseknél szeret választani (Hash és Merge Join). 

A feladat jellegének megfelelően tetszőleges számú táblát 
össze lehet kapcsolni. Pl.: 


SELECT 
CompanyName , 
ProductName, 

FROM 
Customers 

INNER JOIN 
Orders 

ON 
Customers.CustomerID — 

Orders.CustomerID 

INNER JOIN 
[Order Details] 

ON 


Orderpate, 
Products.ProductID 


Orders.OrderID — 
Details] .OrderID 
INNER JOIN 


[Order 





Products 
ON [Order Details].ProductID -— 
Products.ProductID 
CompanyName OrderDate  ProdName 
ProdID 
Blondesd... 
Lehmanns... 
Rattlesn... 


1996-07-25 Alice Mutton 17 
1996-08-13 Alice Mutton 17 
1996-08-30 Alice Mutton 17 


Két dolgot figyeljünk meg a fenti lekérdezésben! Ha olyan 
oszlopot listázunk ki, amelynek neve több táblában is sze- 
repel (pl.: ProductID, OrderID, CustomerID) , akkor meg kell 
jelölni, hogy melyik táblából akarjuk kilistázni az adato- 
kat. Ez INNER JOIN-nál még mindegy lenne, de a többi 
JOIN-nál nagyon fontos lesz. A másik lényeges pont, hogy 
a szóközt is tartalmazó tábla- és oszlopneveket szögletes 
zárójelek (] közé kell tenni. Ugyanez érvényes, ha kulcs- 
szót akarunk használni tábla- vagy attribútumnévnek. 
Where nevű tábla nem túl gyakori, de a User tábla már an- 
nál inkább, ami pedig kulcsszó... 

Az INNER JOIN működéséből következik, hogy az összes 
olyan sor kimarad az eredményből, amelynek nincs párja a 
másik táblában. Azonban a gyakorlatban sokszor az árva 
sorokra is szükség van. A kettővel ezelőtti példánál marad- 
va azokat a vásárlókat is ki szeretnénk listázni, akiknek 
(még) nincsenek megrendeléseik. Ekkor jön segítségünkre 
az OUTER JOIN. Ennek két alfaja van, a LEFT OUTER JOIN 
és a RIGHT OUTER JOIN. Mivel a JOIN kulcsszó mindig két 
tábla között helyezkedik el, a jobb és bal irány értelmezé- 
se természetesen adódik. Amelyik táblát így kitüntetjük, 
abból az összes sor kilistázódik, azok is, amelyeknek nincs 
párja a másik oldali táblában. Így a példánk: 


SELECT 

CompanyName, OrderDate, ShipCity 
FROM 

Customers 
LEFT OUTER JOIN 

Orders 
ON 

Customers.CustomerID - Orders.CustomerID 
Rattlesnake Canyon 1998-05-06 Albuguergue 
Paris spécialités NULL NULL 
FISSA Fabrica NULL NULL 


Ahol az ügyfélhez nincs megrendelés az Orders táblában, 
ott a kiszolgáló NULL-t helyez el azokban az oszlopokban, 
amelyek az Orders táblára mutatnak. Ez egybevág a NULL 
azon jelentésével, hogy , nincs adat". 

Sajnos ezen a ponton be kell fejezzem barangolásomat a 
lekérdezések birodalmában, de ne aggódjanak, a követke- 
ző számban tovább túrunk-fúrunk a SELECT rejtelmeiben, 
hogy azután rátérhessünk az igazi izgalmakra, az adatok 
módosítására. 


Soczó Zsolt, MCSE 
Protomix Kft. 
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Az alábbi cikk kísérleti SP 

jelleggel szerepel lapunk- 
ban: szeretnénk meg- 1ETF 
f mutatni, hogy az Internet életét meghatározó 
MA szabványok (RFC, Reguest For Comments) , me- 
lyekkel minden komoly rendszergazda előbb- 
utóbb szembesül valójában egyáltalán nem szá- 
raz, tudományos értekezések, hanem érdekes mó- 
don gördülékeny, olvasmányos dokumentumok, me- 
lyeket akár még kikapcsolódásképpen is élmény kézbe venni. 
A sorozat szándékunk szerint kéthavonta jelentkezne, s min- 
dig egy-egy teljes RFC fordítását tartalmazza majd. Kérjük 
észrevételeit, a rovat hasznos vagy haszontalan voltát a 
Tech.Netolyris.netacademia.net címen található levelezé- 

si listán írja meg nekünk! 

Köszönettel 
A főszerkesztő 
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RFC 1597: Címkiosztás magáninternetek számára 


E feljegyzés célja 

Ennek a feljegyzésnek az a célja, hogy információkat nyújt- 
son az Internet közössége számára, de nem határoz meg 
semmiféle szabványt, és korlátozás nélkül terjeszthető. 


1. Bevezetés 

Ebben az RFC-ben olyan módszereket teszünk közzé, me- 
lyek az IP címtér gazdaságos kihasználását teszik lehetővé 
azáltal, hogy a magánhálózatok számítógépei számára - 
melyeknek nem szükséges külső kapcsolatokat fenntartani 
- nem igényelünk globális Internetcímeket. Természetesen 
ezek a módszerek továbbra is lehetővé teszik a magánháló- 
zaton belüli kapcsolatokat, sőt a megfelelő gépek külső 
Internetkapcsolatait is. A szerzők azt remélik, hogy ezeket 
használva jelentős megtakarítások érhetők el az egyre fo- 
gyó IP címek kiosztásában. 

Ebben a feljegyzésben a ,, vállalat" szót a továbbiakban egy 
különálló TCP/IP-alapú hálózatot üzemeltető entitásként 
határozzuk meg, amely a magánhálózat címkiosztásának 
részleteit is meghatározza. 


(sZ 





2. Elérendő célok 
A TCP/IP-alapú hálózatok világszerte bekövetkezett elterje- 
désével - az Interneten kívülieket is beleértve — egyre nö- 
vekvő számú olyan hálózat létrejöttét figyelhetjük meg, me- 
lyek egyáltalán nincsenek az Internethez csatlakoztatva. 
Ezek a hálózatok csupán a belső számítógépek összekötésé- 
re használják a TCP/IP protokollt. Sok vállalat a jövőben sem 
fogja magánhálózatát más vállalati hálózatokkal, vagy az 
Internettel összekapcsolni. 
A jelenlegi gyakorlat szerint minden kiszolgáló, mely 
TCP/IP-t használ, globálisan egyedi címet kap. Ám egyre 
többen fejezik ki aggodalmukat amiatt, hogy a véges IP- 
címtér egyszer csak kimerül. Éppen ezért az IP címterek hoz- 
zárendelésére vonatkozó irányelveket jelentősen megszigo- 
rították az utóbbi években [1]. Ezek a szabályok konzervatí- 
vabbak, mint azt a vállalatok - hálózataik megvalósításához 
és működtetéséhez - szeretnék. 

A magánhálózatokon használt, IP-t használó számítógépek 

három kategóriába sorolhatók: 

2 Olyanok, melyeknek nem szükséges más vállalati hálózatok 
gépeivel vagy az Internettel összeköttetésben állni. 

"7 Olyan gépek, melyeknek a külső szolgáltatások (például: 
elektronikus levelezés, FTP, hírszolgáltatás, távoli bejelent- 
kezés) korlátozott részhalmazának elérésére van szüksé- 
gük. Ezt alkalmazásszintű átjárókkal is meg lehet oldani. 
Olyan gépek, melyeknek a vállalati hálózaton kívüli, IP-n 
keresztüli hálózati elérésre van szükségük. 
Az első kategóriába eső számítógépek olyan címeket hasz- 
nálhatnak, melyek a vállalati hálózaton belül egyediek, tá- 
gabb értelemben (vállalatok között) azonban nem. 
A legtöbb második kategóriába eső számítógép számára a kor- 
látozás nélküli külső (IP-n keresztüli) kapcsolat nemhogy szük- 
ségtelen, hanem - biztonsági okokból - egyenesen kerülendő 
is. Ezek a gépek - az első kategóriába esőkhöz hasonlóan - 
olyan címeket használhatnak, melyek csak a magánhálózaton 
belül számítanak egyedinek, de azon kívül nem. 

Csak az utolsó kategóriába eső gépeknek van szükségük 

globálisan egyedi címekre. . 

A legtöbb alkalmazásnak csak a vállalaton belüli kapcsola- 

tokra van szüksége, és csak nagyon kevés külső géppel kell 

kapcsolatot tartania. A nagyobb vállalatoknál könnyen 
meghatározhatók, hogy mely gépeknek van szükségük kül- 
ső hálózati kapcsolatra. 

Néhány példa azokra az esetekre, ahol a külső kapcsolat va- 

lószínűleg nem szükséges: 

2 Repülőtér, ahol az érkezési és indulási adatokat kijelző 
táblák külön címezhetők TCP/IP segítségével. Valószí- 
nűtlen, hogy ezeket a kijelzőket más hálózatok számá- 
ra elérhetővé kellene tenni. 

-? Nagykiterjedésű hálózattal rendelkező szervezetek - pél- 
dául bankok és kereskedelmi értékesítési láncok - melyek 
TCP/IP-re cserélik belső kommunikációs hálózatukat. Itt 
nagyszámú munkaállomás létezhet, például pénztárgé- 
pek, pénzkiadó automaták és egyéb irodai gépek, melyek- 
nek aligha szükséges a külső kapcsolat. 

"2 Biztonsági okokból számos vállalat használ alkalmazás- 
szintű átjárókat (például tűzfalakat) belső hálózatának 
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Internetre csatlakoztatására. A belső hálózatnak álta- 
lában nincs közvetlen Internetelérése, így csak egy 
vagy több tűzfalnak kell láthatónak lennie az 
Internetről. Ebben az esetben a belső hálózat nem egyedi 
IP-címeket is használhat. 

"0" Ha két vállalati hálózat saját kapcsolatain keresztül 
kommunikál egymással, akkor a kapcsolaton át a gé- 
peknek csak egy nagyon korlátozott része érhető el 
kölcsönösen. Csak ezeknek a gépeknek van szüksége 
egyedi IP címekre. 

0 Általában szükségtelen, hogy a belső hálózat útválasz- 
tóinak felülete közvetlenül elérhető legyen a vállalati 
hálózaton kívülről. 


3. A privát címtér 

Az Internet Assigned Numbers Authority (IANA) az IP- 
címtér következő három blokkját foglalta le a magánháló- 
zatok számára: 


10.0.0.O0 - 10.255.255.255 
172.16.0.0 - 172.31.255.255 
192.168.0.0 - 192.168.255.255 


Az első blokkra ,24 bites blokk", a másodikra ,20 bites 
blokk" a harmadikra pedig mint ,, 16 bites blokk" fogunk hi- 
vatkozni. Vegyük észre, hogy az első blokk nem más, mint 
egy A-osztályú hálózat címe, a második blokk 16, egymás 
után következő B-osztályú hálózat címeinek összessége, 
míg a harmadik blokk 255 egymást követő C-osztályú há- 
lózat IP címeinek halmaza. 

A dokumentumban definiált IP címtereken kívüli címek is 
használhatók (azaz az IANA vagy más Internetcím kiosztó 
szervezet által ajánlottakon kívül is választhatunk belső IP 
címeket), de ezek a címek csak a privát hálózatban lesznek 
használhatóak. Ha egy vállalatnak globálisan egyedi cím- 
térre van szüksége, Internetcím kiosztó szervezettől kell 
igényelnie azokat. Az így kapott címtartomány sohasem 
esik a fent definiált tartományokba. 

A privát címtér használatához el kell döntenünk, hogy - belát- 
ható időn belül - mely számítógépeknek van szükségük külső 
kapcsolatra, és melyeknek nem. Ez utóbbiakat - melyek a fent 
meghatározott privát címteret használják - nevezhetjük privát 
számítógépeknek. A privát gépek a magánhálózat bármely más 
- akár privát, akár nyilvános - gépével kommunikálhatnak, de 
nem tudnak külső gépekkel IP kapcsolatot létesíteni. 

A privát gépek annak ellenére, hogy nem rendelkeznek kül- 
ső kapcsolattal, képesek külső szolgáltatásokat igénybe 
venni - alkalmazásszintű átjárók segítségével. 

Minden más számítógépet nyilvánosnak hívunk, mert ezek 
globálisan egyedi címtér-hozzárendeléssel rendelkeznek 
egy Inernetcím kiosztó szervezet jóvoltából. A nyilvános 
gépek a hálózaton belül mind a privát, mind a nyilvános 
gépekkel kommunikálhatnak, valamint külső gépekkel IP- 
alapú kapcsolatot is fenntarthatnak. A nyilvános gépek 
más vállalati hálózatok privát gépeivel nem léphetnek kap- 
csolatba. Egy gép privát státusának nyilvánossá változta- 
tása IP címének megváltoztatásával történik. Mivel a pri- 
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vát címeknek nincs globális jelentésük, az útválasztási infor- 
mációt nem szabad az egyes vállalati hálózatokat összekötő 
kapcsolatokon át terjeszteni, valamint a belső hálózati cím- 
re vonatkozó forrás vagy célcímekkel rendelkező csomagokat 
sem szabad a hálózaton kívülre továbbítani. Elvárható, hogy 
azok az útválasztók, melyek nem használják a privát címteret 
(különösen azok, melyeket az Internetszolgáltatók üzemeltet- 
nek), ne vegyék figyelembe (szűrjék ki) a magánhálózatokról 
származó esetleges csomagokat és útválasztási információt. 
Az útválasztásnak az ilyen információk kiszűrését nem sza- 
bad az útválasztási protokoll hibájaként kezelnie. 

Az ilyen címekre vonatkozó indirekt hivatkozásokat a há- 
lózaton belül kell tartani. Ilyenek például a DNS erőforrás- 
rekordok és más, a magánhálózat belső privát címeire vo- 
natkozó információk. A gyakorlatban az Internetszolgál- 
tatóknak kell megtenniük a megfelelő intézkedéseket, 
hogy a fenti problémákat elkerülhessük. 


4. A privát címtér használatának előnyei és hátrányai 

Az Internet számára nyilvánvaló előny, hogy a privát címtér 
használata megkíméli a globálisan egyedi címteret, hiszen 
azokban az esetekben, ahol nem szükséges, nem használja azt. 
A vállalatok is sok előnyét élvezhetik a privát címtér hasz- 
nálatának: sokkal rugalmasabban alakíthatják ki hálózatu- 
kat a rendelkezésükre álló nagyobb címtér segítségével, 
mint ahogy azt a globálisan egyedi címek használatával te- 
hetnék. Egyúttal lehetővé válik számukra, hogy saját mű- 
ködtetési és felügyeleti igényeiknek megfelelően osszák ki 
a címeket és könnyebben bővíthessék hálózatukat. 

Az Interneten - különböző okokból - már történtek olyan 
esetek, melyeknél a korábban Internethez nem kapcsolt vál- 
lalat az IANA-val nem egyeztetett címteret használt gépei- 
hez. Néhány esetben ezt a címteret már más vállalatok lefog- 
lalták. Amikor eljön az idő, hogy egy ilyen vállalat az 
Internethez kapcsolódjon, súlyos problémákkal kell szembe- 
néznie, mivel a többértelmű címzés miatt az IP útválasztás 
nem fog megfelelően működni. 

A privát címtér használata elkerülhetővé teszi a címzési 
problémákat, s ezzel együtt biztosítja a külső kapcsolat- 
tartás lehetőségét is. 

Persze lehet azon vitatkozni, hogy a címváltoztatás mindig 
fennálló lehetősége vajon jelentős hátrányt jelent-e, ha a há- 
lózati címeket a nem magán Internetek számára kiosztott cím- 
térből választjuk. Azt kell megvizsgálnunk, hogy ez a lehető- 
ség valóban oly fenyegető-e, hiszen sok olyan számítógépet 
használnak, melyet sohasem kell átsorolni a harmadik kate- 
góriába. Olyan hálózatok is szép számmal akadnak, melyeket 
sohasem fognak IP-vel összekapcsolni más hálózatokkal. 

De még ha a címváltoztatás elkerülhető is (a Classless Inter- 
Domain Routing-gal: CIDR) a vállalati hálózat, mely Inter- 
nethez van csatlakoztatva, Internet szolgáltatójának megvál- 
tozása esetén rákényszerülhet nyilvános gépei átcímzésére is. 
Ez a fajta átcímzési kényszer a jövőben valószínűleg gyakrab- 
ban lép majd fel, függetlenül attól, hogy a vállalat a magán- 
hálózatok számára fenntartott címtérből gazdálkodik-e vagy 
sem. Segédeszközök használatával (például DHCP) csökkent- 
hetjük a probléma által okozott fejfájást. 
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Azt is figyelembe kell vennünk, hogy a nyilvános és privát 
gépek világos elkülönítésével a felügyelet nélküli külső elérés 
kockázata csökkeni fog, így a tervezésbe fektetett többlet- 
munkát akár biztonsági intézkedésként is felfoghatjuk. 


5. Üzemeltetési megfontolások 

Az ajánlott stratégia szerint először tervezzük meg a hálózat kül- 
világ elől elzárt részét, a privát címteret használva a belső kapcso- 
latokhoz. Ezután kerítsünk sort a nyílt alhálózatok tervezésére, vé- 
gül a külső kapcsolatokat határozzuk meg. Ez nem a végleges terv. 
Ha bizonyos számú számítógép státuszát kell megváltoztatnunk, 
csak a kérdéses gépeket kell átcímeznünk és ha szükséges, másik 
fizikai alhálózatot kell kiépítenünk. 

Ha megfelelő alhálózati séma tervezhető, és a használatba veen- 
dő eszközeink támogatják, ajánlatos a privát címtér 24 bites 
blokkját felhasználni és a címkiosztási tervbe a hálózat növekedé- 
sét is beleszámítani. Ha az alhálózatok létrehozása problémát je- 
lent, használjuk a 16 bites C-osztályú blokkot, mely 255 egymás 
után következő C-osztályú hálózat címét tartalmazza. 

Több IP (al)hálózat használata egyazon fizikai médiumon szá- 
mos veszélyt rejt magában. Azt ajánljuk, hogy ha csak tehetjük, 
kerüljük el ezt a megoldást, kivéve ha a működtetésben rejlő 
problémákat teljes mértékben megértjük, és minden eszközünk 
képes ennek az üzemmódnak megfelelően működni. 

Egy számítógép státuszának megváltoztatása (privátról nyilvános- 
ra) maga után vonja címének, és a legtöbb esetben fizikai kap- 
csolódásának megváltozását is. Olyan helyeken, ahol ez a fajta 
változás előre látható (géptermek) ajánlatos elkülönített fizikai 
hálózatot használni a nyilvános és a privát alhálózat számára. 
Az összes számítógép státuszának megváltoztatása az egész 
(al)hálózaton egyszerűen végezhető el, anélkül, hogy az egész 
vállalati hálózat működését fel kellene függeszteni. Ebből kö- 
vetkezik, hogy ajánlatos csoportba foglalni azokat a számító- 
gépeket, melyek csatlakozási igényei a jövőben hasonló válto- 
zásokon fognak keresztülmenni saját alhálózatukon. 

Azoknál az útválasztóknál, melyek a vállalati hálózatot kapcsol- 
ják össze a külső hálózattal, nyomatékosan ajánlott, hogy a 
kapcsolat mindkét végén a megfelelő csomag- és 
útválasztószűrőket állítsuk be, hogy megelőzzük a csomagto- 
vábbítás és útválasztási információk okozta problémákat. A vál- 
lalati hálózatnak ki kell szűrnie az összes külső magánhálózat- 
tól származó útválasztási információt, hogy megvédje magát a 
nem egyértelmű útválasztási helyzetektől, melyek akkor léphet- 
nek fel, ha a privát címtér a vállalati hálózaton kívülre mutat. 
Olyan csoportok, melyek előre látják kölcsönös kommuni- 
kációs igényeiket elhatározhatják, hogy közös címkiosztá- 
si terv felállításával közös hálózatot hoznak létre, melyet 
a szükséges szervezeti rendelkezések - például nyilvántar- 
tás - bevezetésével is támogathatnak. 

Ha a vállalat két különböző pontja között külső szolgálta- 
tó bevonásával szükséges összeköttetést létesíteni, akkor 
számításba lehet venni valamilyen IP-alagút használatát, 
mellyel megelőzhető a csomagok elvesztése. 

A DNS bejegyzések elvesztésének elkerüléséhez két névki- 
szolgáló működtetése ajánlott. Egy külső kiszolgáló felelős a 
vállalati hálózat minden globálisan egyedi IP címéért, a má- 
sik a belső névkiszolgáló, mely a vállalati hálózat minden - 
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külső és belső - IP-címéért felel. Az egységesség érdekében 
állítsuk be mindkét névkiszolgálót ugyanazon adatok alapján 
úgy, hogy a külső kiszolgálót csak a számára szükséges DNS- 
információkkal lássuk el. 

Minden belső számítógépen lévő (belső vagy külső névre vo- 
natkozó kérelmet kiszolgáló) névfeloldó csak a belső névki- 
szolgálót kérdezze le. A külső névkiszolgáló a vállalati háló- 
zaton kívüli, külső kérésekkel foglalkozzon, és a globális 
DNS-hez legyen kapcsolva. A belső névkiszolgáló minden, a 
vállalati hálózaton kívülre mutató információkérést irányít- 
son át a külső névkiszolgálóra. Ezzel az elrendezéssel a bel- 
ső gépek hozzájuthatnak a globális DNS információhoz, ám 
a belső gépekről szóló információk nem jutnak el a vállalati 
hálózaton kívül működő számítógépekhez. 


6. Referenciák 
[1] Gerich, E., , Guidelines for Management of IP Address 
Space", RFC 1466, Merit Network, Inc., 1993. május 


7. Biztonsági megfontolások 

Bár a privát címtér használata növelheti a biztonságot, 
nem helyettesítheti a megfelelő biztonsági eszközök és in- 
tézkedések használatát. 


8. Zárszó 

A leírt séma segítségével számos nagyvállalat a globális IP 
címtér viszonylag kevés címblokkjának felhasználásával 
oldhatja meg elérhetőségének problémáját. Az eljárás hasz- 
na a globális IP címtér élettartalmának kitolódása révén 
jelentkezik. A vállalatok a viszonylag nagykiterjedésű privát 
címtér rugalmasságát fordíthatják előnyükre. 
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Elkészült a .net platform el- 
ső hírmondója, a BackOffice 
programcsalád új változata, 
új nevén: .Net Enterprise 
ú lé Servers. A BackOffice kiszol- 
gálócsalád tagjainak legújabb változatait tartalmazó prog- 
ramcsomagot a szeptember 26-i nemzetközi bemutatkozás 
után október 12-én jelentik be Magyarországon. Lapunk kü- 
lönszámmal készült az eseményre, amelyben sorra bemutat- 
juk a család tagjait: ezek az Exchange 2000 Server, az SOL 
Server 2000, az SMS Server 2000, a Host Integration Server 
2000 (korábban SNA Server), az ISA Server 2000 (korábban 
Proxy Server) és természetesen a Windows 2000 Server SP1, 
valamint sok más ,kisebb" összetevő. A Exchange 2000 
Server 120 napos próbaverziója a http: //www.microsoft 
.com/exchange/productinfo/Eval .htm, az ISA Server leg- 
újabb bétája (RC1 - a cikk írásának pillanatában még elérhető) 
pedig a http://www.microsoft.com /isaserver/productin- 


fo/evaledition.htm címről tölthető le. 





Várható Whistler időrend 

A Windows SuperSite-on (http://www.winsupersite.com) ol- 
vasható rengeteg Whistler-információ között megbújik a Mic- 
rosoft új operációs rendszere megjelenésének várható idő- 
rendje is. Ezek szerint a Whistler Beta 1 október közepe tá- 
ján, a Beta 2 valamikor december elején, a majdnem késznek 
mondható RC1 várhatóan 2001 februárjában jelenik meg. Ezt 
követi majd - körülbelül egy hónap múlva - az RC2, majd - 
ha minden jól megy - az RTM (Released To Manufacture, gyár- 
tásra kész) változat, mégpedig állítólag 2001. április 18-án. 
(Lapzártakor ez a terv máris két hetet csúszni látszik... ) 

A Whistler a .net architektúra alapját képezi (mostanában Win- 
dows .NET 1.0-nak is nevezik) , természetesen számos látványos 
és hatékony újítással. Az operációs rendszer Windows 2000 
alapokra épül, a Windows 9x/Me vonal ezzel megszűnni látszik. 
A Whistler aktuális verziójának újdonságait (többek között 
az új, HTML-alapú felhasználói felületet) áttekintő cikk a 
http://www.winsupersite.com/reviews/whistler 2257.a 
sp címen található, rengeteg képernyőképpel meghintve, 


NZZZETOTTT 
7 "Whistler 


Microsoft (R)) Windows 
Version 5.1 (Buld 2257 4dx01.000810-2103) 
Copyright (C) 1981-2000 Merosoft Corp. 





25 éves a Microsoft 

A jövő után tekintsünk egy 
pillanatra vissza a múltba: 
a Microsoft 1975-ös meg- 
alakulása után idén 
nepli 25. születésnapját. 


ün- 


A Microsoft múzeum weblapján (igen, a múzeum a valóság- 
ban is létezik :-) ), a http://www.microsoft.com/mscorij 


/museum/anniversary.asp címen betekinthetünk a Micro- 


soft életének elmúlt negyed századába. 
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Active Directory Client for Windows NT 4.0 
Workstation 

A Windows 2000 megjelenésekor sokan fur- 
csállták, hogy míg a Windows 95/98-ra ké- 

szült Active Directory Client (ami - ha jól 
tudjuk - Windows Me-n egyébként nem műkö- 

dik), a Windows NT 4.0-hoz való példány hi- 
ányzott a Windows 2000 CD-ről. 

Az Active Directory Client for Windows NT 4.0 
Workstation béta változata most letölthető a http:/ 
/www.microsoft. com/windows2000/adclients/ oldalról, 
a végleges változat a Service Pack 7-be fog bekerülni. 





Migr. ír 
44) VisualStudio.net 
Jó hír a fejlesztőknek: itt a Visual Studio.Net Beta 1 
A http://msdn.microsoft.com/vstudio/nextgen 
/betaone.asp cím minden fejlesztőnek kötelező olvas- 
mány. Mire az oldalon található információkon átrágjuk 
magunkat, az MSDN előfizetésben valószínűleg megérkezik 
A fejlesztőkörnyezet a továbbfejlesztett Visual C---, Visual 
Basic és Visual FoxPro mellett természetesen telis-tele lesz 
.net elemekkel: itt az C$, az ADO plus, a Windows Forms, 
XML és SOAP támogatás, minden, amit a .net fejlesztő sze- 
me-szája csak megkívánhat! 


Fe 


Pius 





Végül, egy , személyes" jellegű hír: 
Indul előfizetési akciónk! 


Ha szeretné, hogy magazinunk 
minden hónapban biztosan meg- 
jelenjen postaládájában, fizessen 
elő! Az előfizetési akciónkról ér- 
deklődjön a oldalunkon, a 


http://technet .netacademia.net címen! 





 tech.net! 
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nehézségi fok. 


BIZTONSÁG 
IIS és az 


IIS5 és az NTFS: jogosultsági útvesztők 

Hogyan működik az NTFS jogosultsági 

rendszere? 
Ha a rendszergazda létrehoz egy felhasználói 
fiókot, akkor a Windows ehhez automatikusan 
ho) hozzárendel egy egyedi, biztonsági azonosítót 
hi (SID: Security Identifier), amely egészen a fel- 

használói fiók megszűnéséig létezik. 

Ha a felhasználó hálózati erőforráshoz akar hozzá- 
férni (lásd az alábbi folyamatábra UNC kérelem részét) , 
akkor a felhasználó bejelentkezésekor létrejött a SID-et is 
tartalmazó hozzáférési token a kérelemmel együtt továbbító- 

dik. A fájlrendszer a tokenben lévő SID-et összehasonlítja a 

célobjektum hozzáférés-engedélyezési listájában (ACL: Access 

Control List) szereplőkkel. Találat esetén a listában szereplő 

engedélyeket a felhasználó megkapja, ellenkező esetben a- 

zonban egy hibaüzenettel kell beérnie. 

A fájlrendszerben beállítható, hogy az egyes mappákhoz és 

fájlokhoz bizonyos felhasználók, illetve csoportok, milyen 

jogokkal férhetnek hozzá. Ha adott felhasználónak vala- 
mely fájlhoz olvasási és írási jogot adunk, attól más még 
nem tudja a fájlt írni vagy olvasni. 

A fájlrendszer leggyakoribb jogosultsági szintjei (a Win- 

dows NT és a Windows 2000 jogosultságmegnevezései kicsit 

különböznek egymástól, pl. a Change jognak a Modify felel 
meg Windows 2000-ben): 

0" Full Control (teljes hozzáférés): A felhasználó a fájlo- 
kat és a könyvtárakat módosíthatja, törölheti, áthe- 
lyezheti és újakat hozhat létre. A fájlok és könyvtárak 
tulajdonságai és jogosultságai is állíthatók. 

Change (módosítási jog): A felhasználó megnézheti és 

módosíthatja a fájlokat és tulajdonságaikat, ami magá- 

ba foglalja fájlok létrehozását vagy törlését egy könyv- 
tárban, továbbá fájlok tulajdonságainak módosítását. 

0 Read 8 Execute (olvasási és végrehajtási jog): A fel- 
használó a végrehajtható fájlokat és parancsfájlokat 
futtathatja. 

0 List Folder Content (mappalistázási jog): A felhasz- 
náló megnézheti a mappák tartalmát. 

0 Read (olvasási jog): A felhasználó megnézheti a fájlo- 
kat és azok tulajdonságait. 

0 Write (írásjog): A felhasználó írhat a fájlokba. 

2 No Access (nincs hozzáférés): Ha egyetlen jelölő sincs 
kiválasztva, akkor a felhasználó még abban az esetben 
sem használhatja az erőforrásokat, ha egy maga- 
sabbszintű szülőkönyvtárhoz van hozzáférése. 

Néhány jogosultságra vonatkozó javaslat, melyek segítenek 

biztonságos kiszolgálókat készíteni: 

2 Használjunk NTFS fájlrendszert! 

0 A rendszergazdának legyen mindenhez teljes hozzáféré- 
se, hacsak nem különleges biztonsági követelmények 
indokolják ennek az ellenkezőjét. 

0 A fájlrendszer alapértelmezésben az Everyone (mindenki) 
csoportot minden új könyvtárhoz automatikusan hozzá- 
rendeli teljes hozzáféréssel. Tanácsos ezt azonnal meg- 
változtatni úgy, hogy megfeleljen a biztonsági követel- 
ményeknek. 


a ——— tech.net 
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2 — A helytelenül beállított jogosultságok olyan 
felhasználókat fognak megakadályozni fájlok és könyv- 
tárak elérésében, akiknek erre szükségük van a munká- 
jukhoz. Például hiába van egy felhasználónak olvasási 
és végrehajtási joga egy programra, ha nincs hozzáfé- 
rése egy olyan DLL fájlhoz, amit a program használ. Ha 
a felhasználóknak bizonyos fájlokhoz folyamatosan biz- 
tonságos hozzáférést szeretnénk nyújtani, másoljuk 
ezeket a fájlokat egyazon könyvtárba, majd a könyvtár- 
hoz rendeljük hozzá a megfelelő NTFS jogosultságokat. 


Hogyan működik a web jogosultsági rendszere? 

Ha egy kiszolgáló erőforrásait, például fájlokat szeretnénk 
elérni, akkor a webböngészőnk egy http kérést állít elő, 
majd elküldi a kiszolgálónak. A kérés tartalmazza például a 
hitelesítéshez szükséges adatokat, a kérelem eljárástípusát, 
a kérelem kezdeményezőjének IP címét stb. 


Az IP cím 
engedélyezett? 


as 


0. 


Azonosítás 
sikeres? 


Mé 


A webkiszolgálón 
definiált jogosult- 


a ságok rendben 7 


nem eee. 


Az NTFS 
jogosultságok 


e rendben ve 





Ha a kiszolgáló megkapta a kérést, akkor az IIS először 
megvizsgálja, hogy a kérelem kezdeményezőjének IP címé- 
vel lehetséges-e az erőforrás elérése. Ha igen, akkor az IIS 
ezután rátér a hitelesítési adatok ellenőrzésére. Ha ez is si- 
keres volt, akkor az IIS azt ellenőrzi, hogy a kérelem eljá- 
rástípusa engedélyezett-e az erőforrásra. 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 





A kérés által használt eljárás típusa a HTTP kérelemhez mel- 
lékelt parancs, amely tudatja az IIS-sel, hogy a felhaszná- 
ló milyen módon kíván hozzáférni az erőforráshoz. Ha pél- 
dául egy fájlt szeretnénk megnézni a kiszolgálón, a böngé- 
szőnk ennek megszerzéséhez GET parancsot használna. 
Ezen a ponton két dolog történhet. Ha az IIS anonymous 
hitelesítést használ, akkor ,imitálja" a felhasználót, és a 
nevében eljárva próbál meg a kérdéses erőforrásához hoz- 
záférni. Ha az IUSR számítógépnév felhasználói fiókhoz 
megfelelő jogokat rendeltünk, akkor az IIS a kérelmet jó- 
váhagyja, és a fájl megjelenik a felhasználó böngészőjé- 
ben. Ellenkező esetben az IIS a kérelmet elutasítja, és a 
böngészőben egy hibaüzenetet olvashatunk. 

Ha a hitelesítés típusa ügyfélbizonyítvány alapú, egyszerű, 
integrált Windows vagy digest, akkor az IIS a hitelesítési 
adatokat átadja a Windowsnak, ami megpróbál a címtárban 
ennek megfelelő felhasználói fiókot találni. 


Megjegyzés: Anonymous HTTP kérelmeknél az IIS csak a 
felhasználónév/jelszó részt nem dolgozza fel, de az IP cím- 
re vonatkozó korlátozások, a webes és NTFS jogosultságok 
továbbra is érvényben maradnak. 

A webkiszolgáló hozzáférési engedélyei beállíthatók min- 
den egyes webhelyre, könyvtárra és fájlra. Ezek minden 
felhasználóra érvényesek, függetlenül a rájuk vonatkozó 
egyedi jogosultságoktól. Eszerint, ha egy webhelyre olva- 
sási jogot állítunk be, akkor ez minden felhasználóra vo- 
natkozik (de az egyes felhasználók NTFS jogosultságai ér- 
vényben maradnak). 


Webes jogosultsági szintek: 

0 Read (olvasási jog): Alapértelmezett jog, mellyel a 
felhasználó megnézheti a fájlok tartalmát és a fájlok 
tulajdonságait. 

0 Write (írásjog): A felhasználó megváltoztathatja a 
fájlok tartalmát és a fájlok tulajdonságait. 

0 Script Source Access (forráskód-hozzáférés): A 
felhasználó hozzáférhet a forrásfájlokhoz. Olvasási jog 
esetén a forráskód olvasható, írásjognál a forráskódba 
írni is lehet. A forráskód-hozzáférés engedélyezi a fáj- 
lok forráskódjának, például ASP szkriptek elérését. 
Csak akkor érvényes, ha az olvasási jog vagy az írásjog 
engedélyezett. 

0 Directory browsing (könyvtárböngészési jog): A fel- 
használó megtekintheti a fájlok listáját. 


Figyelem! Ha engedélyezzük a forráskód-hozzáférést, 
akkor a felhasználók az ASP szkriptekből kényes ada- 
tokhoz, például felhasználónévhez és jelszóhoz juthat- 
nak hozzá. Rosszabb esetben megváltoztathatják a ki- 
szolgálón futó alkalmazások forráskódját, ami káro- 
san befolyásolhatja a biztonságot és a teljesítményt. 
Az ehhez hasonló adatok védelme, illetve lehetőségek 
tiltása legegyszerűbben egyedi felhasználói fiókok- 
kal és magas szintű, például Digest vagy integrált Win- 
dows hitelesítéssel oldható meg. 
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A végrehajtási jogosultságok szintjei: 

"? None (semmi): A kiszolgálón szkriptek, például ASP al- 
kalmazások, és végrehajtható fájlok futtatása nem en- 
gedélyezett. 

2 Scripts only (csak szkript): A kiszolgálón csak szkrip- 

tek, például ASP alkalmazások futtathatók. 

Scripts and Executables (szkriptek és végrehajtható 

fájlok): A kiszolgálón szkriptek, például ASP alkal- 

mazások, és végrehajtható fájlok egyaránt futtathatók. 


A WebDAV és a jogosultságok 

A HTTP/1.1 protokoll lehetővé tette a felhasználók számára az 

erőforrások publikálását, zárolását és kezelését a weben. A 

WebDAV (Web Distributed Authoring and Versioning) ezt kibő- 

víti a kérelmek új eljárástípusaival, például a PROPFIND és 

LOCK parancsokkal. Az új parancskészlettel az ügyfélprogra- 

mok képesek az erőforrások és tulajdonságaik módosítására, 

a fájlok zárolására és a zárolás megszüntetésére, továbbá a 

fájlok és tulajdonságok szerinti keresésre. 

A WebDAV-ot integrálták a Windows 2000-rel és az IIS 5.0- 

val, ezek biztonsági rendszerét használja, ami magába fog- 

lalja az IIS-ben meghatározott jogosultságokat és az NTFS 
fájlrendszer hozzáférés-engedélyezési listáit (DACL: Discre- 

tionary Access Control List). Az alábbiakban összefoglaljuk a 

webes jogosultságokat és ezek hatását a kiszolgálón lévő 

erőforrások WebDAV segítségével történő hozzáférésére. 

2 Olvasás, írás és könyvtárböngészés engedélyezése: 
Ezekkel a jogokkal az ügyfél az erőforrásokat listázhatja, 
módosíthatja (kivéve azokat, amelyekre nincs írási joga) , 
saját erőforrásait publikálhatja, és fájlokat manipulálhat. 

2 Írás engedélyezése, olvasás és könyvtárböngészés til- 
tása: Ha az ügyfelek számára lehetővé akarjuk tenni a 
magánjellegű adatok publikálását úgy, hogy ezt mások 
ne láthassák, engedélyezzük az írást, de tiltsuk meg az 
olvasást és a könyvtárak böngészését. Ez a beállítás 
különösen akkor hasznos, ha az ügyfelek szavazócédu- 
lákat vagy teljesítmény-értékeléseket továbbítanak. 

- Írás és olvasás engedélyezése, könyvtárböngészés til- 
tása: Ezt a beállítást akkor használjuk, ha a biztonsá- 
got a fájlnevek elrejtésével kívánjuk megvalósítani. 
Tudnunk kell azonban, hogy ez a biztonságnak egy 
meglehetősen gyenge szintjét eredményezi, mivel a 
fájlnevek próbálkozással előbb-utóbb kitalálhatók. 

2 Erőforrás-indexelés engedélyezése: Ne feledkezzünk 
meg az indexelés engedélyezéséről, ha az ügyfelek szá- 
mára biztosítani akarjuk a keresés lehetőségét. 


A webes és NTFS jogosultságok eltérése 

Ha a webes jogokat csak olvashatónak állítjuk be, akkor ezzel 
az NTFS is csak olvasható lesz? Nem. A webes jogok csak azt 
ellenőrzik, hogy milyen parancsokat használhatunk a HTTP 
kérésekben. Ha az NTFS jogokat csak olvashatónak állítjuk be, 
akkor ezzel a webes is csak olvasható lesz? Igen. Ha az NTFS 
csak olvasható, akkor hiába állítjuk be a webes olvasási és írá- 
si jogokat, a HTTP írási kérelem nem sikerülhet. 

Tegyük fel, hogy készítünk egy ,a" webhelyet, ami egy NTFS 
köteten lévő , a" mappára mutat. Beállítjuk a webes írási és 
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olvasási, illetve az NTFS olvasási jogokat. Ekkor hiába pró- 
bál egy felhasználó a http://www.a.com/ címre írni. Ez 
még akkor sem sikerülne, ha az IIS jóváhagyná az , a" web- 
helyre, tehát az ,a" mappába történő írási kérelmet, mivel 
az NTFS elutasítaná. Ha az , a" webhely hálózatán valaki ír- 
ni próbál az ,a" mappába, az NTFS ezt nem engedélyezi. 
Változtassuk meg a jogosultságokat a következőképpen: az 
NTFS írható és olvasható, míg a webes csak olvasható. En- 
nek eredményeként a webes felhasználó továbbra sem tud 
írni a webhelyre, mert az IIS megtagadja a kérést. A háló- 
zati ügyfél azonban be tudja illeszteni a fájlt a kérdéses 
mappába. Az IIS csak a HTTP kéréseket ellenőrzi, a fájl- 
rendszerre vonatkozó kéréseket már nem. 

Alapszabály: Ha a webes és az NTFS jogosultságok eltérőek, 
akkor a HTTP kéréseknél mindig a szigorúbb érvényesül. 


Jogosultsági varázsló 

Hogyan bizonyosodhatunk meg arról, hogy a webes és az 
NTFS jogosultságok tökéletes összhangban vannak? Erre 
szolgál az IIS jogosultsági varázslója, amely automatiku- 
san összhangba hozza a webes jogosultságokat és az ACL- 
eket. Használható virtuális könyvtár létesítésére vagy mó- 
dosítására is. 

A varázsló használatakor három dolgot kell szem előtt tar- 
tanunk: 

-0 Jegyezzük fel a virtuális könyvtárak, fájlrendszermap- 
pák és fájlok biztonsági beállításait, mielőtt megváltoz- 
tatjuk őket, mert ez jelentősen megkönnyíti a helyreállítást. 
A jogosultsági varázsló az érintett fájlok, fájlrendszer 
mappák és virtuális könyvtárak webes és NTFS jogosult- 
ságait is megváltoztatja. Különleges biztonsági követel- 
mények esetén a webes és NTFS jogosultságokat a va- 
rázsló helyett kézzel kell beállítani. 

A varázsló kevés választási lehetőséget biztosít a könnyű 
használat érdekében. Ezek a beállítások jelenleg nem 
kiterjeszthetők, így nem biztos, hogy minden webhelyre 
használhatók. Különleges biztonsági követelmények 
esetén nézzük át a web és fájlrendszer beállításait. 
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Jogosultsági problémák és megoldásaik 

A webes és az NTFS jogosultságok működésének és a kö- 
zöttük lévő kapcsolat tárgyalása után vessünk egy pillan- 
tást a jogosultsági beállításokkal kapcsolatos gyakori 
problémákra, a valószínű okokra és a megoldásokra. Talán 
ismerősek lesznek, és remélhetőleg segítenek majd a 
zavarbaejtőbb problémák elhárításában is. 
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valószínű ok 


Lehet, hogy a 
weboldalhoz tartozó 
képek egy másik 
könyvtárban vannak, 
amelynek jogosultsá- 
gi beállítása 
megváltozott. 


A képek egy másik 
könyvtárban vannak, 
amelyre integrált 
Windows hitelesítést 
állítottak be. Ez elő- 
fordulhat például a 
FrontPage haszná- 
latánál, vegyes azo- 
nosítású környezet- 
ben. A jogosultsági 
varázsló használata is 
vezethet ilyen ered- 
ményre egy könyvtár 
kizárásával. 


Az azonosítási 
eszköz feltehetően 
zárolta a fájlt 
(LOCK). A feloldása 
néha 30 másod- 
percig tart. 


A webes vagy az 
NTFS írási jog nem 
lett megadva. 


megoldás 
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Összefoglalás 

Könnyen kiismerhetjük magunkat a jogosultságok útvesz- 

tőjében, ha nem felejtjük el a következőket: 

0 AzIIS egy további hozzáférés-ellenőrzési réteget 
helyez az NTFS fölé, nem váltja fel az NTFS-t. Az IIS 
lehetővé teszi a Windows felhasználói fiókkal nem ren- 
delkező, anonymous felhasználók számára, hogy olyan 
erőforrásokhoz férjenek hozzá, amelyekhez egyébként 
nincs engedélyük. Az IIS a Windows fiókkal rendelkező 
felhasználók számára egy további módot is biztosít az 
erőforrások elérésére: HTTP felett WebDAV-val. 

"7 A webes jogosultságok megváltoztatása nem állítja 

át automatikusan az NTFS jogokat, és fordítva, hacsak 

nem a jogosultsági varázslót használtuk erre a célra. 

Ha a webes jogosultságokat kézzel változtattuk meg, 

gondoskodnunk kell ezek NTFS megfelelőiről is. 

Fordítva is igaz: lehet, hogy az NTFS jogok megvátoz- 

tatásakor a webes jogokat is át kell állítani. 

Az NTFS jogok csak arra a felhasználóra és csak arra az 

objektumra vonatkoznak, amelyre beállítottuk. Úgy is 

fogalmazhatunk, hogy az egyes felhasználók NTFS 
jogosultságait objektumonként kell beállítani. Ezzel 
szemben a webes jogok az összes felhasználóra 
érvényesek, akik egy adott webhelyet, könyvtárt vagy 
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BIZTONSÁG / IIS És AZ NTSF 


fájlt szeretnének elérni. A webes jogok ezért az 
összes felhasználóra érvényesek objektumonként. 
Az NTFS jogosultságok mindenfajta elérésre érvénye- 
sek. A webes engedélyek csak a HTTP kérésekre 
vonatkoznak. 

Ha UNC kéréssel próbálkozunk, és nincs hozzáférésünk, 
egy bejelentkezési párbeszédablak jelenik meg, amely 
egy engedéllyel rendelkező azonosító megadására 
szólít fel bennünket. Ha ilyennek nem vagyunk a bir- 
tokában, akkor ez az ablak gyakori vendégünk lesz. 
Megfelelő jogosultság nélküli HTTP kérelemre a ,403: 
Access denied" (hozzáférés megtagadva) hibaüzenetet 
kapjuk. 

Az IUSR számítógépnév fiókot az IIS automatikusan 
létrehozza anonymous hozzáférési joggal. Ahhoz, hogy 
mitálni" tudja a felhasználókat, és biztosítsa számukra 
az anonymous hozzáférést, az IUSR számítógépnév 
fiókot el kell látnunk helyi bejelentkezési (Log On 
Locally) joggal, és a Guest csoport tagjává kell tennünk. 
Ha szeretnénk az IUSR számítógépnév fiókot megváltoz- 
tatni, például le akarjuk cserélni a jelszavát, akkor 
készítsünk egy új fiókot, például ANON számítógépnév 
névvel, és használjuk ezt. Az IUSR számítógépnév fiók 
megváltoztatása megjósolhatatlan problémákhoz vezethet. 
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Az Active Directory egyszerű kezelése az ADSI 
segítségével 
Valószínűleg már mindenki hallott a Windows 
Active Directory-ról. Az Olvasóban felmerül- 
het a kérdés, hogy miért hasznos ez, miért 
van szükség rá. Egyszerűen azért, mert igazi 
Windows 2000 hálózati környezetben a címtár 
használata elkerülhetetlen. Amikor bejelentke- 
zünk egy Windows 2000 tartományba, működésbe 
lép az Active Directory; ha az irodánk épületében 
meg akarjuk keresni a legközelebbi színes nyomtatót, a 
címtár segít. A címtárobjektumok közötti keresés vagy a 40. 
épületben dolgozó felhasználók nevének listázása sem je- 
lenthet gondot. Az alkalmazások telepítése is könnyebb: az 
Active Directory segít az alkalmazások és összetevőik (kom- 
ponenseik) keresésében és telepítésében. Mindezek mellett 
ma már smart card-ot is használhatunk a Windows 2000 tar- 
tományba történő bejelentkezéshez: a nyílt kulcsú bizton- 
sági infrastruktúra főbb elemei mind-mind az Active 
Directory-ra támaszkodnak. 
További példáink is vannak: Tetszetős jelentéssel akarjuk el- 
kápráztatni főnökünket? Az Active Directory-val ez néhány 
perc alatt megvalósítható. Összekapcsolhatjuk a Microsoft 
SOL Server és a címtár adatait? Természetesen igen. 
A fenti okokon kívül fontos az is, hogy sok más Microsoft 
technológia, például a Microsoft Message Oueue Server 
(MSMO), a COM (az objektumosztályok könyvtára, a Class 
Store), az IPSec, a Group Policy Objects (GPO) és az 
Exchange az Active Directory-t használják. Az Active 
Directory szolgáltatásait a jövőben egyre több és több al- 
kalmazás fogja kihasználni. 
Az Active Directory speciális adatbázis - nem rendszerleíró 
adatbázis (mint a registry) és nem is egy szokásos adatbá- 
zis (mint az SOL Server) - inkább keresési, kevésbé változ- 
tatási és frissítési műveletekre lett optimalizálva. Az Active 
Directory az adatokat hierarchikusan, többszörözve és bővít- 
hetően tárolja. A többszörözés (azaz replikáció, több 
címtárkiszolgáló közös működéséhez szükséges szinkronizáci- 
ós adatfogalom) miatt nem tárolhatunk benne dinamikus 
adatokat, mondjuk Internetes tőzsdei árfolyamokat, pro- 
cesszorteljesítmény-mutatókat, sem más, hasonló jellegű 
információt. A számítógép-specifikus adatoknak például ma 
még inkább a rendszerleíró adatbázisban a helyük. Ösz- 
szességében azt mondhatjuk, hogy a címtárban viszonylag 
statikus, globális és megosztható adatokat tárolunk. A cím- 
tárban tárolható adatokra tipikus példák a nyomtató-vára- 
kozási sorok, a felhasználók adatai és a hálózat, valamint a 
számítógép beállításai. Az Active Directory címtáradatbázis 
objektumokat tartalmaz (mégpedig elvileg bármilyet) , min- 
den objektumnak egy vagy több saját jellemzője, attribútu- 
ma lehet. Az, hogy a címtárban milyen objektumokat tárol- 
hatunk, és azoknak milyen attribútumaik lehetnek, a séma 
(schema) határozza meg. 
Felmerülhet a kérdés, hogy milyen objektumokat tárol je- 
lenleg az Active Directory. A Windows 2000-ben az Active 
Directory három partícióból (más néven névtér, Naming 
Context) áll: tartomány (domain), séma (schema) és konfi- 
gurációs (configuration) partícióból. A tartománypartíció 
felhasználói felülete az alábbi ábrán látható. Ez tárolja a 
felhasználókat, a felhasználói csoportokat, a kapcsolatokat, 
a számítógépeket, a szervezeti egységeket és sok más ob- 
jektumtípust. Mivel az Active Directory bővíthető, saját 
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osztályokat és attribútumokat is adhatunk hozzá. A máso- 
dik partíció, a séma az objektumosztályok és attribútumaik 
meghatározását tartalmazza. Végül a konfigurációs partíci- 
óban az Active Directory rendszerszolgáltatások, partíciók 
és telephelyek beállítási adatait találjuk. 
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Az Active Directory tartománypartíciója 


Csatlakozás az Active Directory-hoz 

Az Active Directory-hoz több különböző módon is hozzáfér- 
hetünk. A Microsoft az Active Directory hozzáférés legfon- 
tosabb eszközeként az ADSI használatát ajánlja. Az ADSI a 
címtárakkal való kommunikáció céljára kifejlesztett LDAP 
protokoll segítségével éri el az Active Directory-t. Kezdjük 
néhány egyszerű példával. (Az egyszerűség kedvéért minden 
példát Microsoft Visual Basic-ben írtunk...) 

Elsőként csatlakozzunk a címtárhoz: 

Set ns -— GetObject(,LDAP:") 

Ennyi az egész. Az ADSI segítségével most (ha minden jól 
ment...) csatlakoztunk az alapértelmezett Active Directory 
tartományvezérlőhöz. Az ADSI az úgynevezett locator szol- 
gáltatás segítségével megkeresi a számunkra legmegfelelőbb 
tartományvezérlőt (domain controller, DC). (A locator szol- 
gáltatás lényegében a telephelyre vonatkozó információk se- 
gítségével határozza meg az adott ügyfél számára legmegfe- 
lelőbb tartományvezérlőt.) Nem kell foglalkoznunk olyan ,lé- 
nyegtelen" dolgokkal, mint a kiszolgálónév, hiszen a címtár- 
nak éppen az információ központosítása lenne az egyik leg- 
főbb célja. Ezt a megoldást kiszolgáló nélküli csatlakozásnak 
nevezzük (server-less binding). 

De mi van akkor, ha mi történetesen szeretjük a kiszolgáló- 
neveket használni? Nos, az ADSI a kiszolgálónév meghatá- 
rozását is lehetővé teszi. 

Set obj - GetObject(,LDAP://mysrvO1l") 
Más esetben előfordulhat, hogy csak a tartománynevet tud- 
juk, a kiszolgálónevet pedig nem. Az ADSI a tartománynév 
megadását is lehetővé teszi. A Windows 2000-ben a tarto- 
mánynév DNS névként jelenik meg. 


Set obj -— 
GetObject( , LDAP : //netacademia.net") 


Az ADSI így a netacademia.net tartomány egyik tartomány- 
vezérlőjéhez csatlakoztat minket. 
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Az ArcadiaBay Corporation 

Az ArcadiaBay egy kitalált vállalat (amit kitalált amerikai 
magyarok vezetnek :-) ). Ezt a vállalatot használjuk fel egy 
szervezet tipikus helyzeteinek bemutatására. 

Az ArcadiaBay nemrég frissítette tartományát Windows NT 
4.0-ról Windows 2000-re. Józsi, a rendszergazda, nagyon 
érdeklődik az Active Directory használata iránt. Természete- 
sen ismeri a Windows 2000 Support Tools részeként szállí- 
tott Active Directory-kezelő eszközöket, de ez a cikk nem az 
adminisztrációs eszközökről, hanem a programozási hozzá- 
férésről szól. Józsi a telepítés során az ,arcadiabay.com" 
DNS tartománynevet adta meg. A meglévő felhasználók, fel- 
használói csoportok és számítógépek mind-mind az új arca- 
diabay.com tartományba kerültek át. 

Mielőtt folytatnánk, álljunk meg itt egy kicsit. Először is 
tudnunk kell, hogy az Active Directory hogyan nevezi el az 
objektumokat. A fájlneveken keresztül mutatunk egy pél- 
dát: minden fájl rendelkezik egy névvel és egy elérési út- 
vonallal. A fájlnévnek természetesen az adott elérési útvo- 
nalon egyedinek kell lennie. Vegyük a következő példát: 
cApublicispecstadsi25.doc". Ebben az esetben a fájl- 
név  ,adsi25.doc", a teljes elérési út pedig 
,c:YMpublicispecstadsi25.doc." 

Az Active Directory-ban az objektumok ehhez bizonyos 
szempontból hasonlóan kapnak nevet. Minden objektum 
rendelkezik egy objektumnévvel vagy másképpen relatív 
megkülönböztető névvel (relative distinguished name, RDN), 
és egy objektumelérési útvonallal, azaz megkülönböztető 
névvel (distinguished name, DN). Az RDN vagy objektum- 
név két részből áll: az attribútumazonosítóból (attribute 
ID) és magából az értékből. Például DCsArcadiaBay. A DC 
egy RDN attribútumazonosító, amely a tartomány ösz- 
szetevőre utal, az ArcadiaBay pedig az attribútum értéke. 
Esetünkben az Arcadiabay tartományobjektum megkülön- 
böztető neve DC-ArcadiaBay, DC-Com. Látható, hogy a DN 
több, egymástól elválasztott RDN-ből áll, amelyek mind- 
egyike azonosítót (például DC) és értéket (például 
ArcadiaBay) is tartalmaz. 

Ezek szerint a tartományobjektumhoz a következőképpen 
kapcsolódhatunk: 


Set dom — 
GetObject ( , LDAP : / /DC-ArcadiaBay , DC-Com" ) 


A tartományobjektum megtalálása után kiírathatjuk annak 
néhány attribútumát: 


Debug.Print dom.Get(,Name") 
Debug.Print dom.Get(,whenCreated") 


Szervezeti egység (Organizational Unit, 0U) létrehozása 
Maradjunk a tartományobjektumnál, tegyük egy kicsit ér- 
dekesebbé a helyzetet. Az ArcadiaBay Értékesítési (Sales) 
és Termelési (Production) osztályból áll. A vállalat azt ter- 
vezi, hogy felvesz két Windows 2000 rendszergazdát, 
mindkét osztályra egyet. Józsi, a vállalat fő rendszergaz- 
dája, két új szervezeti egységet hoz létre az ArcadiaBay 
tartományban. A szervezeti egység létrehozásával Józsi 
sok objektumot csoportosíthat, és lehetővé teheti, hogy 
azokat valaki más kezelje (,kiadja" a munkát). A Sales 
szervezeti egységet (Organizational Unit, OU) a következő- 
képpen hozhatjuk létre: 
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Set salesOorg — 
dom.Create(,organizationalUnit" , 
rOU5-Sales") 


salesOrg.Put , description", 
Headguarter, SF" 


Sales 


salesOrg.Put , wwwHomePage", 
"http: //arcadiabay.com/sales" 
salesOrg.SetInfo 


Jöjjön egy kis magyarázat. A Create eljárás adja meg az osz- 
tálynevet és az új objektum nevét. A visszakapott objektum 
attribútumai a Put metódus hívásával módosíthatók, ehhez 
meg kell adnunk a módosítandó attribútum nevét és érté- 
két. Az objektum és a benne történt módosítások egyelőre 
nem a címtárban jöttek létre, hanem a memóriában, egy 
gyorsítótárban. A SetInfo eljárás meghívásakor a változta- 
tások (ebben az esetben az objektum létrehozása és az attri- 
bútum módosítása) bevésődnek a címtárba. A változtatás 
tranzakcióalapú, ami azt jelenti, hogy ha az adatok menté- 
se során valami hiba történne (elmenne az áram), a rend- 
szer biztos, hogy nem kerül , félállapotba". Esetünkben ez 
azt jelenti, hogy vagy létrejön az új objektum az összes vál- 
toztatással együtt, vagy nem változik semmi (ekkor az ob- 
jektumot sem fogjuk találni) . Belátható, hogy a sok rossz kö- 
zül ez a legkevésbé kellemetlen eset. 

A Termelési osztály szervezeti egység létrehozása legyen 
házi feladat. Egymásba illeszthetők a szervezeti egységek? 
Igen! Tételezzük fel, hogy a Sales osztályt tovább bontjuk 
a keleti (east) és nyugati (west) régió szerint. 


Set east — 
salesOrg.Create(,organizationalUnit", 
rO0U-East") 

east.SetInfo 


Ugyanezt a nyugati régióval is megtehetjük. 
csatlakozni, adjuk meg a szervezeti egység teljes megkü- 
lönböztető nevét. 


Set east -— GetObject(,LDAP://OU-East, 
OoUu-Sales, DC-ArcadiaBay, DC-COM") 
Debug.Print east.Get ,description" 
east.Put ,wwwHomePage", 

"http: //arcadiabay.com/sales/east" 


Ha már csatlakoztunk a szülőobjektumhoz (Sales), a szülő- 
objektumból is csatlakozhatunk a származtatott objektum- 
hoz (East). 


Set east 5 
salesOU.GetObject(,organizationaluUnit" , 
rO0U-East") 


Honnan tudjuk, hogy tényleg létrehoztuk-e ezeket az új 
objektumokat? Használjuk az Active Directory Users and 
Computers MMC modult és megláthatjuk. Az új szervezeti 
egységeknek ott kell lenniük. 
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Meglévő felhasználók telepítése a szervezeti egységbe 
A Windows NT 4.0 tartomány frissítésekor az összes fel- 
használó és csoport az ArcadiaBay tartomány , Users" map- 
pájába került. Helyezzünk át néhány felhasználót a szá- 
mukra megfelelő szervezeti egységbe. Az ADSI használatá- 
val egyébként egy objektumot más Windows 2000 tartomá- 
nyokba is áthelyezhetünk. 


Set usr — 
salesOU.MoveHere ( , LDAP : //CN-mikeg, CN-Users , 
DC-ArcadiaBay , DC—COM", vbNullString) 


A MoveHere megkapja az áthelyezendő objektum 
AdsPath-jét (a szolgáltató nevét, amely a következőkből 
áll: LDAP és egy megkülönböztető név; ez valójában az ADSI 
objektum egyedi neve, ezzel az attribúűtummal minden ADSI 
objektum rendelkezik) és az új objektumnevet (RDN). Ha az 
eredeti nevet akarjuk megtartani, egy nullát adjunk meg. 
Ha az objektumot át akarjuk nevezni, az új nevet a máso- 
dik paraméterként adhatjuk meg. A példában Michael Gray- 
t (mikeg) helyezzük át a Sales szervezeti egységbe. 

Az AdsPath a részletes leírása megtalálható az MSDN 
Library-ban, az ADSI dokumentációban. 


Új felhasználók létrehozása a szervezeti egységben 

A Sales szervezeti egységbe felvettek egy új, Julie Adam 
nevű alkalmazottat. Ő lesz Michael Gray új főnöke. Józsi- 
nak új felhasználói fiókot kell létrehoznia számára. Józsi 
(ahelyett, hogy két kattintással megtenné :-) ) billentyűze- 
tet ragad, és gépelni kezd: 


Set salesOU — 

GetObject ( , LDAP : //OU-Sales , DC-ArcadiaBay 
, DCECOM" ) 

Set usr - salesOU.Create(,user", 
.CN-Julie Adam") 

usr.Put ,samAccountName", ,juliea" 
usr.Put ,userPrincipalName", 
njulieGgarcadiabay. com" 

usr.Put ,title" ,Marketing Manager" 
usr.SetInfo 


usr.SetPassword , seahorse" 
usr.AccountDisabled - False 
usr.SetInfo 


Meg kell adnunk tehát például a samAccountName attribútu- 
mot - ez a felhasználói osztály egyik kötelező attribú- 
tuma, az objektum létrehozása előtt pedig minden 
kötelező attribútumot ki kell töltenünk. A felhasználó 
samAccountName attribútuma a Windows NT 4.0-és Windows 
9.x számítógépekről történő bejelentkezéskor használt 
felhasználónevet tartalmazza. Természetesen ezt a nevet 
a Windows 2000-ben is használhatjuk. Mi vajon a 
userPrincipalName? A Windows 2000 környezetben (ha mind 
az ügyfél, mind a tartományvezérlő Windows 2000-et futtat), 
az úgynevezett User Principal Name-mel (UPN) is bejelentkez- 
hetünk. Példánkban Julie UPN-je julieDarcadiabay.com. 

Józsi jogaival élve a SetPassword eljárással a jelszót is 
megadhatja. A SetPassword eljárás csak akkor működik, 
ha az objektumot a címtárban már ténylegesen létrehoztuk 
(emlékezzünk a gyorsítótárra!). Ezért mielőtt beállítjuk a 
felhasználó jelszavát, meg kell hívnunk a SetInfo metó- 
dust. Végül az AccountDisabled tulajdonság hamisra 
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(FALSE) állításával engedélyezzük a felhasználó fiókját. 
Tegyük Julie-t Michael főnökévé. 





Set usr 5 
GetObject ( , LDAP : //CN-mikeg, 
DC-ArcadiaBay, DC-COM") 
usr.Put ,manager", ,CN-Julie 
Adam,0U-Sales, DC-ArcadiaBay, DC-COM" 
usr.SetInfo 


oUussSales, 


Itt felmerülhet egy lehetséges probléma. Mi történik ak- 
kor, ha Julie megváltoztatja a nevét, átkerül egy másik 
szervezeti egységbe vagy kilép a vállalattól? Ki tartja kar- 
ban ezt a közvetlen beosztotti kapcsolatot? Ezt majd ké- 
sőbb, az átszervezési gyakorlatnál tekintjük át. Még egy 
megjegyzés: mivel az Active Directory séma bővíthető, az 
objektumok modellezésénél könnyen létrehozhatunk hason- 
ló közvetlen beosztotti kapcsolatokat. 

A következő feladat előtt nézzük meg, hogy kik Julie köz- 
vetlen beosztottai. 


Set usr — 

GetObject( , LDAP: //CN-Julie Adam, 
0O0Uu-Sales, DC-ArcadiaBay, DC-COM") 
reports - usr.GetEx (,directReports") 


For Each directReport in reports 
Debug.Print directReport 
Next 


Azt látjuk, hogy a közvetlen beosztott Michael G, pedig nem 
is állítottuk be a directReports attribútumot. Az Active 
Directory ,automágikusan" kezeli a főnök-beosztott viszonyt. 
Mi az a GetEx eljárás? A címtárak világában egy attribú- 
tumnak egy vagy több értéke lehet. Mivel tudjuk, hogy a 
directReports többértékű (ez a sémából és a dokumentáci- 
óból is látszik) , egyszerűbb a GetEx használata, amely min- 
dig egy eredménysort ad vissza, függetlenül attól, hogy 
egy vagy több értékről van-e szó. A For Each segítségével 
pedig egyenként listázhatjuk az eredményeket. 

A közvetlen beosztotti kapcsolatok az Active Directory 
Users and Computers MMC modulban, a felhasználó tulaj: 
donságlapján is megtekinthetők. 


Új csoport létrehozása 

Józsinak egy új csoportot kell létrehoznia. A csoport tag- 
jai számára azután elérhetővé akar tenni néhány erőforrást 
(fájlokat, Active Directory-beli vagy más objektumokat). 


Set ou — 

GetObject ( , LDAP : //OUu5-Sales , DC-ArcadiaBay , 
DC-COM" ) 

Set grp — ou.Create(, group" , 
rCN-Management" ) 

grp.Put ,samAccountName" , 
grp.Put ,groupType", 

ADS GROUP TYPE DOMAIN LOCAL GROUP Or 
ADS GROUP TYPE SECURITY ENABLED 
grp.SetInfo 


agmi 


Ezt a ,Management" nevű csoportot a Sales szerveze- 
ti egységben hoztuk létre. Először is a Sales szerveze- 
ti egység ADSI objektumára van szükségünk. A 
samAccountName a kompatibilitáshoz szükséges kötelező 
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attribútum. Példánkban a Windows NT 4.0-s eszközök (pél- 
dául a Felhasználókezelő) számára a csoport neve ,mgmt", 
és nem , Management". A csoport típusát is meg kell hatá- 
roznunk. A Windows 2000 tartományban három csoporttí- 
pust használhatunk: globális (Global), tartományi helyi 
(Domain Local) és univerzális (Universal) csoportot, emel- 
lett a csoporthoz adatvédelmi jellemzők is tartoznak. A 
csoport lehet biztonsági (Security) vagy adatvédelem nél- 
küli. A biztonsági csoportok az erőforrások hozzáférési jo- 
gainak listájában szerepelhetnek (csakúgy, mint az egysze- 
rű felhasználók). A másik fajta, úgynevezett terjesztési 
(vagy disztribúciós) listák nem használhatók ugyanígy - 
egy terjesztési listának például nem adhatunk hozzáférési 
jogokat az erőforrásokhoz. A rendszer frissítése során a 
Windows NT 4.0-ból származó csoportok biztonsági csopor- 
tokká alakultak. Az Active Directory adatvédelem nélküli 
csoportjai az Exchange terjesztési (levelezési) listáihoz ha- 
sonlatosak, a Windows 2000-ben nagyon hasonló a csopor- 
tok és a terjesztési listák létrehozásának művelete. A Win- 
dows 2000 címtár natív üzemmódjában a csoportok bármi- 
lyen szintig egymásba illeszthetők. Ha a címtár vegyes 
(mixed) módban üzemel, a tartományvezérlők között még 
szerepelhet Windows NT 4.0 kiszolgáló is. 


Felhasználók hozzáadása egy csoporthoz 
Adjuk hozzá Julie-t a Management csoporthoz. 


Set grp — 

GetObject ( , LDAP : //CN-Management , 
0U-Sales, DC-ArcadiaBay, DC-COM") 
grp.Add (,LDAP://CN-Julie Adam, 
0O0Uu-Sales, DC-ArcadiaBay, DC-COM") 


A fenti példa magáért beszél: Add eljárásnak átadtuk Julie 
azonosítóját, így ő bekerült a csoportba. 


Az objektumok számlálása 

Gyakran van szükség arra, hogy megszámoljuk a címtár egy 
mappájában vagy szervezeti egységében tárolt objektumo- 
kat. A mappa gyermekobjektumainak számbavétele során 
kilistázzuk a címtár-hierarchiában közvetlenül a tároló 
alatt található objektumokat. A fájlrendszerben ez annak 
felel meg, amikor egy adott könyvtár fájljait ellenőrizzük. 
Ha akarunk, egy szinttel feljebb is léphetünk, így egy 
adott objektum szülőobjektumát tekinthetjük meg. 


Set ou - GetObject(, LDAP: //OU-Sales, 
DC5-ArcadiaBay, DC-COM") 
For Each child in ou 
Debug.Print child.Name 
Next 


Az objektumok számlálása során kiszűrhetünk adott típusú 
objektumokat. Ha például csak a felhasználókat és a cso- 
portokat akarjuk megtekinteni, a listázás előtt (For Each) 
állítsuk be a szervezeti egység Filter attribútumát, aminek 
egy osztálynevekből álló füzért kell átadnunk (erre való az 


Array()): 


Ou.Filter - Array(,user", ,group") 
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Egy objektum szülőobjektumának nevét a Parent attribú- 
tum tartalmazza. Ha a név már megvan, könnyen csatla- 
kozhatunk a szülőobjektumhoz is: 


obj.Parent 
GetObject(parentPath) 


parentPath 
Set parent — 


Objektumok keresése 

Julie-nak meg kell keresnie a 101. osztályon dolgozó 
összes programmenedzser telefonszámát. Segítsünk neki 
létrehozni erre egy olyan script-et, amely az adatbázisok 
eléréséhez fejlesztett programozói felületet, az ADO-t 
(ActiveX Data Objects) és az ADSI-t is használja. 


"ADO Connection és Command objektum lét- 
rehozása 
Set con - CreateObject-( , ADODB. Connection") 
Set com CreateObject ( , ADODB . Command" ) 

: A kapcsolat megnyitása 
con.Provider - ,ADsDSOObDject" 
ADSI-OLEDB provider neve 
con.Open ,Active Directory Provider" 

:" A Command objektumot hozzárendeljük a 
létrejött kapcsolathoz 
Set Com.ActiveConnection -— 


(Ez az 


con 


"A keres?kérdés összeállítása 

Com. CommandText -— , SELECT 

name , telephoneNumber FROM 

"LDAP : //DCsArcadiaBay, DC-com" WHERE 
objectCategory-—" Person" 

AND objectClass — "user" 

AND title-"Program Manager" 

AND department-101" 


"(A keresés futtatása 
Set rs - Com.Execute 


4 


:" Az eredménytábla (RecordSet) listázása 
While Not rs.EOF 
Debug.Print rs.Fields(,Name") § , , 
rs.Fields(, telephoneNumber" ) 
rs.MoveNext 
Wend 


n § 


Huh, ebben a cikkben ez az első tíz sornál hosszabb prog- 
ramkód. Ha az olvasó ismeri a Microsoft ActiveX Data 
Objects-et (ADO), ez gyerekjátéknak tűnhet. Visual Basic- 
ben vagy scriptkörnyezetben egy ADSI keresés végrehajtá- 
sához három dologra van szükség: kapcsolatra 
(Connection) , parancsra (Command) és eredménytáblá- 
ra (Recordset). A Connection objektumban megadhatjuk 
a címtárkiszolgáló nevét és más jellemzőket. A Command 
objektumban a keresési feltételeket és a lekérdezés szöve- 
gét adhatjuk meg, gyakorlatilag magát a parancsot. A le- 
kérdezés végrehajtása előtt a Connection objektumot 
össze kell kapcsolnunk a Command objektummal. Végül a 
Recordset objektum használható az eredményhalmaz ke- 
zelésére. 

Az ADSI a lekérdezés szövegezésének két formáját támo- 
gatja. Az előbbi példa az SOL formát mutatja be, azonban 
az LDAP formát is használhatjuk. Az LDAP lekérdezési szö 
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veg az RFC 2254 szabványra épül. Az előző példa a követ- 
kezőképpen fordítható le LDAP lekérdezésre: 


Com. CommandText — 

r ZLDAP : / /DCsarcadiaBay , DC-COM ; (§ (objectCa 
tegory-Person) (objectClass-user) (title-Pro 
gramManager) (department-101) ; name , telephon 
eNumber ; subTree" 


Mit jelent a subTree szó a szöveg végén? A címtár világá- 
ban megadhatjuk a keresés hatókörét. A következőkből vá- 
laszthatunk: base (alap), oneLevel (egyszintű) és subTree 
(alkönyvtáras). A base csak magát az objektumot olvassa 
be; a oneLevel a , dir" parancshoz hasonlóan a közvetlen 
származtatott objektumokat is; a subTree pedig a dir /s- 
hez hasonlóan több szinten is keres. 

Az SOL forma használatával a hatókör a parancs tulajdon- 
ságai között adható meg. Például: Command.Properties 
(Search Scope") - ADS SCOPE ONELEVEL. Ha nem adjuk 
meg a hatókört, az alapértelmezésben subTree keresés lesz. 


Átszervezés 

Az egész Sales szervezeti egység átkerül egy új szervezeti 
egységbe - a , Sales and Support"-ba. Julie-t (nyilván az 
általa írt lekérdezőscript hatására) előléptetik alelnökké, ő 
lesz az új szervezeti egység vezetője. 


Set dom — 
DC-COM" ) 
Set salesSupport - 

dom.Create( ,organizationalUnit", ,CN-Sales 
and Support") 

Set sales -— 

salesSupport .MoveHere ( , LDAP : //ou-Sales , 
DCsArcadiaBay, DC-COM", vbNullString) 


GetObject ( , LDAP : //DC-ArcadiaBay , 


Három sor kód egy átszervezéshez nem rossz, ugye? Így a 
sales szervezeti egység minden objektuma, a szervezeti al- 
egységeket is beleértve, átkerült az új szervezeti egységbe. 
Helyezzük át Julie-t a Sales and Support szervezeti egységbe. 


Set usr — 

salesSupport.MoveHere ( , LDAP : //CN-Julie 
Adam, 0O0U-Sales, 0U-Sales and Support, 
DCsArcadiaBay , DC-COM" ) 

usr.Put ,title", ,Vice President" 
usr.SetInfo 


Felmerülhet a kérdés, hogy mi történt a Julie és Michael kö- 
zötti közvetlen beosztotti kapcsolattal. , Ki teszi rendbe ezt a 
kapcsolatot?" - kérdezhetjük. Mint azt talán az Olvasó már ki 
is találta, az Active Directory , automágikusan" elintézte ezt. 


Heterogén adatbázisok adatainak összekapcsolása 

A szervezetek adataikat általában több heterogén adatbázis- 
ban tárolják: a humán erőforrások adatait például SOL 
Server-en, a felhasználói fiókokkal kapcsolatos információ- 
kat a címtárban, egyéb információkat pedig más, egyedi for- 
mátumokban. Így az adatok eléréséhez szükséges különbö- 
ző programozói felületek, protokollok és adatformátumok 
használatai miatt a több forrásból származó adatok egyetlen 
használható jelentésbe való összevonása nem egyszerű. 

Az SOL Server 7.0 Distributed Ouery-vel, az ADSI-val, az 
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OLEDB-vel és az Active Directory-val lehetővé válik az Active 
Directory és az SOL Server adatainak összekapcsolása. Az 
összevont adatokat később meg is tekinthetjük. Ennek lépései: 


Az SOL Server-ben 

1. Futtassuk a Ouery Analyzer-t (Start ] Programs ] 
Microsoft SOL Server 7.0) 

2. Jelentkezzünk be az SOL Server számítógépre. 

3. Hajtsuk végre a következő sort (jelöljük ki és nyomjunk 
CTRLA-E-t): 


sp addlinkedserver "ADSI", "Active 
Directory Service Interfaces", 
"ADSDSOObDbject", "adsdatasource" 

go 


Ez utasítja az SOL Server-t, hogy az , ADSI" szót kapcsolja 
össze az ADSI OLE DB szolgáltatóval, az , ADSDSOObject"- 
tel. Így az SOL Server-ből hozzáférhetünk az Active 
Directory-hoz. 

4. Írjuk be és hajtsuk végre a következőket: 


SELECT " FROM Openluery( ADSI, "SELECT name, 
adsPath FROM , LDAP://DC-ArcadiaBay, DC-com" 
WHERE objectCategory - , Person" AND objectClassz 
User") 


5. Az ADSI LDAP formát is használhatjuk. Példa: 


SELECT § FROM 

OpenOuery(ADSI, " CLDAP : //DCsArcadiaBay;D 
C-COM ; (§ (objectCategory-Person) (object 
Classzuser));name, adspath;subtree") 


Nézet létrehozása és megtekintése 

Nézetet is hozhatunk létre az Active Directory-ból szárma- 
zó adatok megtekintésére, Fontos, hogy csak a nézet defi- 
níciója tárolódik az SOL Server-en és nem a tényleges ered- 
ményhalmaz. Így előfordulhat, hogy egy-egy későbbi vég- 
rehajtás során más eredményt kapunk. A nézet létrehozá- 
sához a következőket írjuk be és hajtsuk végre: 


CREATE VIEW viewADUsers AS 
SELECT $ FROM Openguery( 
ADSI, " CLDAP : //DC-ArcadiaBay , DC—com ; (§.(obj 
ectCategory-Person) (objectClasszuser) ) ; 
name, adspath,title;subtree") 
A nézet megtekintéséhez a következőket írjuk be: 


SELECT $ from viewADUSsers 
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Heterogén kapcsolat az SOL Server és az Active 
Directory között 

Az ArcadiaBay alkalmazottait hathavonta értékelik. Az értéke- 
lés eredményét az SOL Server humán erőforrás (Human 
Resource) adatbázisában tárolják. Először is hozzunk létre egy 
táblázatot az alkalmazottak teljesítményének áttekintéséről: 


CREATE TABLE EMP REVIEW 
( 

userName varChar(40), 
reviewDate datetime, 
rating decimal 


) 
Írjunk be néhány bejegyzést: 


INSERT EMP REVIEW VALUES( Julie Adam", 
12/15/1999", 4 ) 

INSERT EMP REVIEW VALUES( "Julie Adam", 
"7/15/1999", 5 ) 

INSERT EMP REVIEW VALUES( "Michael Gray", 
s2/19/71998-, 31 

INSERT EMP REVIEW VALUES-( "Michael Gray", 
17/15/1999", 4 ) 


Kapcsoljuk össze a kettőt - az Active Directory felhaszná- 
lói objektumait és az SOL Server táblázatot: 


SELECT ADsPath, userName, 
ReviewDate, Rating 
FROM EMP REVIEW, viewADUsers 
WHERE userName - Name 


title, 


Voila! Mind az SOL Server-ből, mind az Active Directory-ból 
megkaptuk az eredményeket. Az AdsPath és a Title oszlop 
az Active Directory-ból, míg a username, a ReviewDate és 
a Rating az SOL táblázatból származik. Ehhez a kapcsolat- 
hoz más nézetet is létrehozhatunk: 


CREATE VIEW reviewReport 
SELECT ADsPath, userName, 
ReviewDate, Rating 
FROM EMP REVIEW, viewADUsers 
WHERE userName - Name 


title 


RootDSE 

Minden címtárkiszolgáló rendelkezik egy RootDSE nevű 
egyedi bejegyzéssel. Ez a kiszolgálóról szolgáltat informá- 
ciókat - például a kiszolgáló szolgáltatásairól, az általa tá- 
mogatott LDAP verzióról, a rajta található névtérről stb. 
Tételezzük fel, hogy egy olyan scriptet vagy alkalmazást 
szeretnénk létrehozni, amely bármilyen Windows 2000 tar- 
tománykörnyezetben képes futni. Az Active Directory-hoz 
történő csatlakozáskor a megkülönböztető nevet, a kiszol- 
gálónevet vagy a tartománynevet is megadhatjuk. Mi van 
akkor, ha nem rendelkezünk ezekkel? Ekkor a RootDSE ob- 
jektum siet a segítségünkre. A következő példa bármilyen 
tartományban megváltoztatja a tartományleírást: 
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Set rootDSE -— 

GetObject ( , LDAP : //RootDSE") 

Set dom - GetObject( ,LDAP://" § 
rootDSE.Get ( , defaultNamingContext")) 
dom.Put ,description", ,My domain" 
dom.SetInfo 


A defaultNamingContext attribútummal a RootDSE-ben 
az aktuális tartományhoz csatlakozhatunk (az Arcadia Bay- 
ben a defaultNamingContext: dc-ArcadiaBay, DC-COM). 


Szervezeti egységek felügyeletének delegálása 

Az ArcadiaBay két rendszergazdát (Miki és Pali) vett fel az 
East és a West szervezeti egység kezelésére. Józsi lehető- 
vé teszi számukra, hogy saját szervezeti egységükben ők 
hozhassanak létre és törölhessenek le felhasználókat: 


Set ou - GetObject(, LDAP: //OU-East, 
0U-Sales, DC-ArcadiaBay, DC—COM") 

Set sec - ou.Get(,ntSecurityDescriptor") 
Set acl -— sec.DiscretionaryAcl 


"vagy: Set ace - new 
ADsAccessControlEntry 

Set ace — 

CreateObject ( ,AccessControlEntry") 


"Engedélyezés 

ace.AceType — 

ADS ACETYPE ACCESS ALLOWED OBJECT 
"Létrehozás és törlés jog 
ace.AccessMask — 

ADS RIGHT DS CREATE CHILD Or 

ADS RIGHT DS DELETE CHILD 

"A felhasználó objektumosztály GUID-ja a 
sémában: 

ace.ObjectType - , (BF967ABA-ODE6-11DO- 
A285-0O0AA003049E2)" 

ace.AceFlags -— ADS ACEFLAG INHERIT ACE 
"Jog öröklésének beállítása 

ace.Flags - ADS FLAG OBJECT TYPE PRESENT 
ace.Trustee - , ARCADIABAYWMiki" "? a 
kedvezményezett 

acl.AddAce ace 


sec.DiscretionaryAcl — acl 
ou.Put ,ntSecurityDescriptor" Array(sec) 
ou.Setlnfo "Tárolás az Active Directoryban 


Set ace - Nothing 
Set acl - Nothing 
Set sec -— Nothing 


Egy kicsit komplikált, ugye? 

Az Active Directory-ban (egyébként a Windows NT-ben és 
Windows 2000-ben is -— a szerk.) minden objektum rendel- 
kezik egy úgynevezett adatvédelmi leíróval Security 
Descriptor). Az adatvédelmi leíró határozza meg, hogy az 
objektummal ki és mit művelhet. Maga az adatvédelmi le- 
író két hozzáférési listát (Access Control List, ACL) tartal- 
maz, amelyeket Discretionary ACL-nek (DACL) és System 
ACL-nek (SACL) nevezünk. Minden ACL hozzáférési bejegy- 
zéseket (Access Control Entry, ACE) tartalmazhat. Maga az 
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kat. Az ACE a jogosult személye mellett a számára engedé- 
lyezett vagy éppen tiltott műveletet is meghatározza. Ilyen 
műveletek például a gyermekobjektum törlése vagy létreho- 
zása, az objektumjellemzők olvasása vagy írása. Azt is meg- 
határozhatjuk, hogy az ACE milyen objektumosztályokra 
vagy attribútumokra fejtse ki a hatását. Példánkban a wser 
(felhasználó) osztályt választottuk. Ezután a következő kér- 
désre kell válaszolnunk: ,.Kire vonatkozik ez az ACE?" Pél- 
dánkban Mikit adtuk meg. Végül meg kell határoznunk az 
ACE öröklődési tulajdonságait - megadható például, hogy az 
ACE a hierarchiában öröklődjön. 

Összegzésképpen: az előbbi példa azt eredményezi, hogy 
Miki képessé válik felhasználói objektumokat létrehozni és 
törölni az East Sales szervezeti egységben, Az alábbi ábra 
az Active Directory Create New View menüjét mutatja a 
kód futtatása után. Ha Józsiként (rendszergazdaként) je- 
lentkezünk be, több létrehozható osztályt is láthatunk. Ha 
Mikiként, csak felhasználói objektumokat hozhatunk létre. 
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Az új objektum létrehozására szolgáló menü két külön- 
böző felhasználó számára 


A globális katalógus (Global Catalog) 

Több tartományt összekapcsolhatunk úgy, hogy tartományi 
fát (tree) alkossanak, több tartományfából pedig tartományi 
erdőt (forest) hozhatunk létre. A közös erdőben található 
partíciók ugyanazt a séma- és beállítási partíciót használják. 
Az erdő minden objektumáról egy globális katalógusban 
(Global Catalog, GC) lista készül, de egy adott erdőhöz egy- 
nél több globális katalógus is tartozhat. A globális katalógus 
mindig tartományvezérlőn található, de egy tartományvezér- 
lő nem feltétlenül üzemeltet globális katalógust. A globális 
katalógusba nem minden attribútum kerül be, csak az általunk 
kiválasztott attribútumok jelennek meg benne. 

A globális katalógus elsődleges célja a vállalati szintű ke- 
resések biztosítása: ha például Józsi szeretné tudni, kik 
azok a felhasználók, akiket az elmúlt 30 napban vettek fel. 
Ha programból szeretnénk kapcsolódni a globális kataló- 
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gushoz, az LDAP: helyett a GC:-t kell használnunk: 


Set gc — GetObject(, GC: //srvOl.arcadiabay.com") 
Set gc — GetObject(,GC://DC-Arcadiabay, 
DC-COM") 


Ha az Europe.ArcadiaBay.com az ArcadiaBay.com egy 
gyermektartománya, a GC://DC-ArcadiaBay,DC-Com 
globális katalógus a Europe.arcadiabay.com objektuma- 
it is magába foglalja. 


Az ADSI bővítmények 

Az ADSI bővítmények segítségével a címtár egy objektum- 
osztályát összekapcsolhatjuk saját COM objektumunkkal. 
Aki az objektumot ezután ADSI-n keresztül éri el, úgy ér- 
zékeli, mintha az adott attribútum vagy metódus az ADSI 
objektum sajátja volna. 

Például: amikor az ArcadiaBay-hez egy új alkalmazott lép 
be, a rendszergazda a címtárban egy új felhasználói objek- 
tumot hoz létre, a bérelszámoló pedig bejegyzést készít a 
humán erőforrás adatbázisban. Az ADSI bővítménnyel ez a 
folyamat egyetlen scriptbe foglalható. 


Set usr - ou.Create(,user", ,CN-Alice 
Johnson") 

// ... attribútumok beállítása ... 
usr.SetInfo 

usr.AddToPayroll " ez egy ADSI bővítmény- 
metódus 


Debug.Print ,A(z) , § usr.Name § , fel- 
használót létrehoztam" 


További olvasmányok: 
Active Directory Services Interfaces 2.5 telepítő 
(ADSI 2.5 és providerek) 


W2K: ADSI 2.5 telepítésére nincs szükség 

NTA: http://www.microsoft.com/ntserver/nts/down- 
loads/other/ADSI25/x86.asp 

W98: http://www.microsoft.com/ntserver/nts/down- 
loads/other/ADSI25/w98.asp é 
W95: http://www.microsoft.com/ntserver/nts/down- 


loads/other/ADSI25/w95.asp 
MSDN Library: http://msdn.microsoft.com/library 
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Micresoft 


E hónapban is - már-már hagyományszerűen - a NetAcademia 
levelezési listák elmúlt havi forgalmából mazsolázunk. 
Hisszük, hogy az itt felmerülő kérdések nagy része szélesebb 
körű nyilvánosságot is érdekelhet. Ha Önnek is kérdése van, 
és kiváncsi az ország többszáz szakértőjének a véleményére, 
iratkozzon fel levelezési listáinkra a (http: //www.neta- 
cademia.net/ ?page-lyris.htm) címen, és kérdezzen bátran! 


K: Megjelent a Windows 2000 Service Pack 1. Az előzetes 
leírásokban volt arról szó, hogy a Windows 2000 javító- 
csomagjait be lehet építeni a telepítőkészletbe, hogy ké- 
sőbb már ne kelljen ezzel is kínlódni. Hogy is van ez? 


V: A Service Pack 1 képes beépülni a Windows 2000 erede- 
ti telepítőkészletébe. A kulcs az update.exe kapcsolóiban 
rejlik. A -z kapcsoló hatására például elmarad a telepítés 
utáni újraindítás, a -g esetén felhasználói beavatkozás 
nélkül, csendben folyik a telepítés, a -n megadásakor pe- 
dig nem készül biztonsági másolat az eredeti fájlokról 
(helytakarékosság...). Végül itt van a -s: mappanév kap- 
csoló, ahol megadhatjuk az eredeti telepítőkészlet i386 
könyvtárat tartalmazó mappájának elérési útját. (Tehát, ha 
a telepítőkészlet az E: IW2KSETUPIi386 könyvtárban találha- 
tó, akkor a parancs így néz ki: update.exe -—s:EJW2KSETUP). 


K: Ha nekem a hálózatos SP1 telepítőkészlet van meg 
(sp1network.exe) , akkor mit tehetek? 


V: Az splnetwork.exe a -x kapcsoló segítségével kitömörít- 
hető úgy, hogy maga a telepítés nem kezdődik meg (csak lét- 
rejön a javítócsomag telepítőjét tartalmazó csomag, benne az 
update.exe-vel). Ha az spilnetwork.exe-nek bármilyen más 
kapcsolót megadunk, az továbbítódik az update.exe felé (ma- 
gyarán szólva, az első válaszban az update.exe helyére bárho- 
va nyugodtan behelyettesíthetjük az sp1network.exe-t is). 


K: Van valami érdekesség a javítócsomagok közben meg- 
jelent gyorsjavításokkal is? Engem például a hideg kiráz, 
amikor arra gondolok, hogy a tizenkét hotfix telepítése- 
kor tizenkétszer újra kell indítani a számítógépet... 


V: Természetesen, hiszen különben a kérdés nem szerepelne eb- 
ben a rovatban :-). A hotfix.exe mindig más néven je-lentkezik: 
ORHHHHH XXX YYY ZZZ LL.exe, ahol tttttttttt a hiba leírását tar- 
talmazó tudásbázis-cikk száma (ld. Microsoft Knowledge Base), 
XXX az operációs rendszer jele, YYY a javítócsomag, amiben 
(majd) megtalálható a javítás, a ZZZ a hardverplatform, LL pedig 
a nyelv jele. Engedtessék meg, hogy a továbbiakban egyszerűen 
hotfix.exe-ként hivatkozzunk rá. 

A hotfix.exe kapcsolói többek között: -y: uninstall (ügyeljünk a 
megfelelő sorrendre!) , -n: nincs biztonsági mentés, -z: nincs új- 
raindítás, -[: a telepített javítások listája (!). Ez utóbbi kapcso- 
lónak egyébként könnyű dolga van, hiszen minden telepített 
hotfix a HKLM MSoftwarelMicrosoftWWindows NT) Current Version 
MHotfixtcütttttttHtHtt- címszó alatt bejegyzi magát a registrybe. 





DUPLA KV 


K: Van néhány kellemes funkció a felhasználói fe- 
lületben, amit a (Windows) gomb segítségével 
könnyen elérhetünk, például a W--M (minden 
ablak minimalizálása) , vagy a WE (explorer 
indítása). Van arra valami mód, hogy kiter- 
jesszük ezeket a lehetőségeket? 


V: Aki szorgalmas olvasója a NetAcademia leve- 
lezési listáinak, az már hallhatott a winkey nevű 
kellemes kis  segédeszközről. A program a 


http://www.copernic.com/winkey címről ingyen letölt- 


hető, és indítás után csendben megbújik a háttérben. 
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K: Ha már a felhasználó felület , tuningolásánál" tar- 
tunk: a nemrég letöltött TweakUI indításkor valami le- 
járt próbaidőszakról üzenget, és azután természetesen 
használhatatlan. Hogy járhat le egy ingyenes program? 


V: Ez a hiba a TweakUI egyik bétájában található, bevalott 
dolog. Ahogy kiderült, rögtön meg is jelent egy javított 
változat, de azzal igazából már nem érdemes sokat foglal- 
kozni, ugyanis azóta megjelent a legújabb, 1.33-as válto- 
zat is. A Windows ME-n és Windows 2000-n is biztonsággal 
használható eszköz letölthető a Microsoft weblapjáról: 
http://www.microsoft.com/ntworkstation/downloads 


/PowerToys/Networking/NTTweakUI.asp 


K: Térjünk vissza egy kicsit a Windows NT 4-hez. Igaz az, 
hogy ha egyszer egy NT 4 Server-t tartományvezérlőként 
(PDC vagy BDC) telepítettünk, abból újratelepítés nélkül 
nem lehet Standalone kiszolgálót faragni (és viszont)? 


V: Igen, igaz és nem, nem igaz. Hivatalosan a 
PDC/BDC/Standalone szerepváltáshoz elkerülhetetlen az 
újratelepítés, de szerencsére van, aki ebbe a hivatalos 
álláspontba nem nyugodott bele. A http://u-tools.com 
/UTools/UPromote.asp címről letölthető UPromote nevű 
ügyes kis eszköz mégis képes erre! 


EIT: 
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Web Distributed Authoring and Versioning 
(WebDAV) 
A weben elhelyezett oldalakat megtekinteni 
könnyű, azonban megváltoztatni azokat ko- 
rántsem az. Ha az intranetek ilyen lehetőség- 
get is rendelkeznének, sokkal hatékonyabbá 
válna a használatuk. 
Ennek a hiánynak a pótlására készült a Web 
Distributed Authoring and Versioning (WebDAV) ne- 
vű szolgáltatás, melyet az IIS 5.0 teljes mértékben tá- 
mogat. A WebDAV a HTTP 1.1 szabvány kiterjesztése, mely le- 
hetővé teszi, hogy HTTP-kapcsolaton keresztül bármilyen táro- 
ló médium tartalmát kezelhessük (például egy fájlrendszert). 
A webkiszolgálónkon felállított WebDAV könyvtáron keresz- 
tül a felhasználók megoszthatják dokumentumaikat. A távol 
dolgozó munkatársak úgy használhatják a nekik kiosztott 
könyvtárat, mintha az a saját gépükön lenne: fájlokat és 
könyvtárakat mozgathatnak, kereshetnek, szerkeszthetnek 
vagy törölhetnek a kiszolgálón. 
A WebDAV lehetővé teszi a fájlhozzáférési engedélyek hasz- 
nálatát, a kapcsolatmentes (offline) szerkesztést, a fájlok 
integritásának megőrzését, a párhuzamos változtatásokból 
eredő konfliktusok feloldását. Az IIS 5.0 WebDAV szolgálta- 
tása a következőket nyújtja: 
0 Az erőforrások kezelése. A felhasználók módosíthatják 
a WebDAV nyilvános könyvtárában található fájlokat. 
Tulajdonságok megváltoztatása. A felhasználók lekér- 
dezhetik és módosíthatják az erőforrások tulajdonságait 
Erőforrások zárolása és felszabadítása. Több felhasz- 
náló egyidejűleg is olvashat egy fájlt, de egyszerre csak 
egy módosíthatja azt. Ennek biztonságos megvaló- 
sításáról az erőforrások zárolása gondoskodik. 
Fájlok tulajdonságai és tartalma szerinti keresés. A 
WebDAV könyvtárában lévő fájlokat akár tulajdonságaik, 
akár tartalmuk szerint kereshetjük. Keresést kezdemé- 
nyezhetünk például olyan fájlok után, melyek a , tábla" 
szót tartalmazzák, vagy amelyeknek , Feri" a szerzője. 
Ugyanezen a szolgáltatáson alapul az Office rovatban 
ismertetett Office Server Extensions. 
A IIS felügyelő eszközei segítségével WebDAV könyvtár felállí- 
tása éppoly egyszerű, mint egy virtuális könyvtáré. Miután lét- 
rehoztuk a közzététel céljára szolgáló könyvtárat, a megfelelő 
jogosultságokkal rendelkező felhasználók dokumentumokat te- 
hetnek közzé, és kezelhetik az itt található fájlokat. 
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Office 2000 
ügyfél 


Windows 2000 
ügyfél 


Internet 
Explorer 5.0 


Dokumentumok megosztása a WebDAV segítségével 


A WebDAV könyvtárak elérése a Microsoft különféle termékei 
mellett olyan alkalmazásokkal lehetséges, melyek támogat- 
ják az ipari szabványnak számító WebDAV protokollt. 

2 Windows 2000-rel az Add Network Place (Hálózati 
hely hozzáadása) varázslóval kapcsolódhatunk a 
WebDAV könyvtárhoz, mely ezután saját gépünk 
fájlrendszerének szerves részeként szerepel. A kapcsoló- 
dás után fájlokat másolhatunk ebbe a könyvtárba, mó- 
dosíthatjuk a fájlok jellemzőit, és sok más fájlrendszer- 
re jellemző feladatot is elvégezhetünk. 
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My Network Places 


Use this folder to open files and 
folders on other computers and to 
install network printers. 

To set up networking on your 
computer, click Network and Dial-u 
Connections. 

Select an item to view its description. 


See also: 
My Documents 
My Computer 


2 objectís) 





Windows 2000-ben a Hálózati hely hozzáadása varázs- 
ló segítségével létesíthetünk kapcsolatot a WebDAV ki- 
szolgálóval 
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0 A Microsoft Internet Explorer 5 segítségével a fenti- 
hez hasonló módon kapcsolódhatunk a WebDAV könyv- 
tárhoz, és ugyanazokat a fájlrendszerbeli műveleteket 
végezhetjük el. 

0 A Microsoft Office 2000 bármely alkalmazása képes a 
dokumentumokat közvetlenül a WebDAV könyvtárban 
létrehozni, szerkeszteni, elmenteni és ott közzétenni. 
Mivel megfelelő engedélyek birtokában bárki írhat a 
WebDAV könyvtárba, fontos, hogy korlátozni tudjuk 
annak elérését. Az integrált Windows hitelesítés 
használatával biztosíthatjuk, hogy csak a megfelelő 
engedélyekkel rendelkező felhasználók érhessék el az 
intraneten megosztott WebDAV könyvtárat. 


Webmappák 
A WebDAV könyvtárakra, vagy a bennük található állomá- 
nyokra mutató parancsikonokat webmappáknak, vagy HTTP 
mappáknak nevezzük. Ezek a parancsikonok a Hálózatok 
(My Network Places) mappában automatikusan létrejön- 
" nek, amikor a WebDAV szolgáltatással rendelkező kiszolgá- 
lón valamilyen erőforrást nyitunk meg és írási /olvasási 
joggal is rendelkezünk. Ezen kívül az Add Network Place 
(Hálózati hely hozzáadása) varázslót is felhasználhatjuk a 
webkiszolgálókra és más számítógépekre mutató parancs- 
ikonok létrehozásához. 
A webmappák használatával a felhasználók úgy érezhetik, 
mintha a távoli kiszolgálón lévő könyvtár saját fájlrendsze- 
rük részét képezné. A webmappákat is a Windows-ban 
megszokott felhasználói felületet segítségével érhetjük el, 
így látszólag nincs különbség a helyi fájlrendszer, hálóza- 
ti meghajtó vagy egy Interneten lévő webhely tartalmának 
böngészése között. Egy kis eltérés mégis feltűnhet: a 
webmappa tartalmának megjelenítésekor a benne találha- 
tó fájlok internetes címe is megjelenik. 


Az IIS és az elosztott fájlrendszer (Dfs) 

Az IIS 5.0 kihasználja a Windows 2000 elosztott fájlrendsze- 
rében (Distributed File System - Dfs) rejlő lehetőségeket. A 
Dfs egyetlen névtérben egyesíti a különböző számítógépeken 
tárolt állományokat, segítségével egyetlen, hierarchikus 
rendszerben egyesíthetjük a hálózat különböző kiszolgálóin 
található információkat, megkönnyíthetjük a fájlok elérését. 
Ha a webhely gyökérkönyvtárának Dfs gyökérkönyvtárat 
adunk meg, akkor úgy módosíthatjuk a webhely erőforrá- 
sainak helyzetét (például egyik kiszolgálóról egy másikra 
mozgathatjuk őket), hogy a webhely HTML fájljaiban egyet- 
len hivatkozást sem kell megváltoztatni. (A Dfs-fában a 
Windows Media szolgáltatások fájljai is tárolhatók. ) 


HTTP tömörítés 

A HTTP tömörítéssel a tömörített lapok fogadására alkal- 
mas böngésző meggyorsíthatja a letöltést. Ez azokban a 
helyzetekben jelenthet komoly előnyt, ahol a sávszélesség 
korlátozott. A tömörítéssel elérhető sebességnövekedés a 
weblapok tartalmától, a kiszolgáló teljesítményétől és ter- 
helésétől is függ. Ha a webkiszolgáló főként dinamikus ol- 
dalakat generál, vagy a webkiszolgálót működtető gép pro- 
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cesszorkihasználtsága eléri a 8090-ot, akkor nem érdemes 
a kiszolgálót a tömörítéssel tovább terhelni. 


Újrakezdhető FTP letöltés 

A szabványos File Transfer Protocol (FTP) szolgáltatás a 
Windows 2000 Server szerves részét képezi, sőt az IIS 5.0 
az újrakezdhető FTP protokollt is támogatja. Ennek kö- 
szönhetően a kapcsolat megszakadása esetén a letöltést a 
szakadás helyétől lehet folytatni. 


Biztonság 

A Microsoft együtt dolgozik az Internetes számítógépes 

közösséggel, hogy elősegítse a szabványok kialakulását és 

beépítse azokat termékeibe. Az IIS 5.0 a következő bizton- 
sági szabványokat támogatja: 

0 Fortezza. Az IIS 5.0-ban újdonság az Amerikai Egye- 
sült Államok kormányzata által javasolt szabvány, a 
Fortezza támogatása. A Fortezza megfelel a Defense 
Message System biztonsági architektúrának, biztosítja 
az üzenetek bizalmasságát, integritását, hitelességét, 
megváltoztathatatlanságát, és az üzenetekhez, kompo- 
nensekhez és rendszerekhez való hozzáférés felügyeletét. 

"0 Secure Sockets Layer (SSL 3.0). Az SSL biztonsági 
protokollokat széles körben alkalmazzák az 
Internetböngészők és kiszolgálók a hitelesítés, üze- 
net-biztonság megőrzése és a bizalmas információk 
védelme érdekében. Webkiszolgálónk SSL biztonsági 
modulját beállíthatjuk, hogy ellenőrizze a felhasználók 
kilétét és kódolja a hálózaton átküldendő adatokat. 

2 Transport Layer Security (TLS). A TLS az SSL-en alapul. 
Képes a felhasználók biztonságos azonosítására és a 
programozók számára lehetővé teszi, hogy olyan TLS-t 
felhasználó kódot írhassanak, mely anélkül képes más 
folyamatokkal kódolt információk cseréjére, hogy a kó- 
dot létrehozó programozónak a többi program kódját 
ismernie kellene. A TLS-t arra fejlesztették ki, hogy 
olyan keretrendszert biztosítson, melyet új, nyílt kul- 
csú és más kódoló algoritmusok is felhasználhatnak. 

"2 PKCS $7. Ez a protokoll a digitális aláírások, vagy digitális 
borítékok formátumát határozza meg, melyek az infor- 
mációt biztonságos formában őrzik. Az IIS hitelesítési 
folyamataiban mindkettőt felhasználja. 

2 PKCS H1O. Ezt a protokoll a nyílt kulcsú tanúsítványok 
formátumát írja le, melyeket a tanúsítványokat kibocsá- 
tó szervezethez (CA) küldenek el. 

0 Alapszintű hitelesítés. A Basic Authentication a HTTP 
1.0 specifikáció része, a jelszavakat Base64 formá- 
tumban továbbítja. Ez a módszer rendkívül elterjedt, 
ipari szabványnak számít a felhasználói nevek és jel- 
szavak továbbításában. A Basic Authentication előnye, 
hogy a HTTP szabvány része, ezért ez a legismertebb 
hitelesítő módszer a böngészők között. A probléma 
csak az, hogy a jelszavakat nem titkosítja, így a háló- 
zati forgalom figyelésével (melyre könnyen elérhető 
eszközök állnak rendelkezésre) könnyen megszerezhe- 
tők az ilyen módon átvitt jelszavak, ezért ez a módszer 
csak azokban az esetekben ajánlható, amikor a web 
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böngésző és a kiszolgáló közti összeköttetés lehallga- 
tásbiztos, például közvetlen kábelkapcsolat, vagy de- 
dikált vonal esetén. 

2 Digest Authentication. Az IIS 5.0 egyik újdonsága a 
Dígest Authentication, mely ugyanazokkal a lehe- 
tőségekkel bír, mint a Basic Authentication, de más 
módon végzi a bizalmas információ átvitelét. A hi- 
telesítésre szolgáló információ egyirányú kódolási folya- 
maton (hashing) halad át. A folyamat eredményét 
hash-nek vagy message digest-nek hívjuk, melyből az 
eredeti szöveget nem lehet visszakódolni. A kiszolgáló 
kiegészítő információkat is hozzácsatol a jelszóhoz, 
mielőtt azt kódolná, így senki sem tudja a kódolt jel- 
szót arra felhasználni, hogy segítségével később jogo- 
sulatlanul az igazi felhasználónak adja ki magát. Ez a 
Digest Authentication legnagyobb előnye, hiszen a 
Basic Authentication esetén a jelszó elfogása után 
bárki jogosulatlanul használhatta a jelszó eredeti tu- 
lajdonosának biztosított szolgáltatásokat. A Digest 
Authentication proxy kiszolgálókon és tűzfalakon ke- 
resztül is működik, és a Web Distributed Authoring and 
Versioning (WebDAV) számára is elérhető. Mivel azon- 
ban ezt a lehetőséget a HTTP 1.1-es szabványában de- 
finiálták, nem minden böngésző támogatja. Ha olyan 
böngésző küld kérelmet a Digest Authentication-t 
igénylő kiszolgálóhoz, mely nem képes e biztonság- 
technikai módszer használatára, a kiszolgáló megta- 
gadja az együttműködést, és hibaüzenetet küld vissza. 
E módszer ma még csak azokban a tartományokban 
használható, melyeknek tartományvezérlője Windows 
2000-alapú, ügyféloldalon pedig Internet Explorer 5.0, 
vagy újabb böngésző működik. 


Biztonsági elemek 

Az IIS 5.0-ban használt öt fő biztonsági elem a következő: 

0 Hitelesítés, a felhasználók kilétének ellenőrzéséhez. 

0 Tanúsítványok, a webhelyet azonosító információk 
biztonságos küldéséhez és fogadásához. 

0 Elérési jogok, a webhelyen lévő tartalom védelméhez. 

0 Kódolás, a tartalom megváltoztatásának megakadályo- 
zására. 

7 Auditálás, a biztonsággal összefüggő tevékenységek 
naplózásához. 


A hitelesség megállapítása 

A hitelesítés segítségével megbizonyosodhatunk. arról, 

hogy az, aki el akarja érni a szolgáltatásainkat, jogosult-e 

a belépésre. Az IIS 5.0 a következő hitelesítési módszere- 

ket támogatja: 

2 Anonymous Authentication. Ez a módszer bárki számá- 
ra belépési lehetőséget biztosít a web- vagy FTP-kiszol- 
gáló nyilvános területeire anélkül, hogy jelszót kérne. 
Ha az Anonymous Authentication engedélyezve van, 
az IIS először megpróbálja ezzel a módszerrel belép- 
tetni a felhasználót, akkor is ha más módszerek is 
engedélyezve vannak. Ha a felhasználó a web- vagy 
FTP-helyünk nyilvános részeire akar belépni, akkor 
webkiszolgálónk az IUSR számítógépnév felhasználói 
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fiókot rendeli hozzá, ahol a számítógépnév annak a ki- 
szolgálónak a neve, amelyen az IIS fut. Ha több web- 
helyet működtetünk kiszolgálónkon, vagy webhelyünkön 
különböző elérési jogokat igénylő területeket tartunk 
fenn, akkor több anonymous fiókot hozhatunk létre. Min- 
den egyes web- vagy FTP hely, könyvtár vagy akár fájl 
számára hozzunk létre egy külön anonymous fiókot. 
Nyílt jelszavas FTP hitelesítés. Az FTP kapcsolat kiala- 
kításához a felhasználóknak be kell jelentkezniük a ki- 
szolgálóra, megadva felhasználói nevüket és jelsza- 
vukat. Ha a kiszolgáló nem tudta azonosítani a beje- 
lentkező felhasználót, hibaüzenetet küld vissza. A nyílt 
jelszavas FTP-hitelesítés nem tartozik a biztonságos 
módszerek közé, hiszen a felhasználói név és jelszó 
kódolatlanul utazik a hálózaton. 

2 Anonymous FTP hitelesítés. FTP-kiszolgálónkat úgy is 
beállíthatjuk, hogy tegye lehetővé az anonymous el- 
érést. Ekkor az IIS ezt próbálja meg először, akkor is, 
ha a Basic Authentication is engedélyezve van. 

0 Integrált Windows hitelesítés. Ezzel módszerrel lehe- 
tőség van arra, hogy a felhasználót a Windows-t futta- 
tó számítógépek egymás között azonosítsák. Így a fel- 
használónak csak egyszer kell bejelentkeznie a Win- 
dows 2000 tartományba, a további erőforrások eléré- 
séhez nincs szükség további azonosításra. 

A korábban NTLM-nek vagy Windows NT Challenge /Response 
hitelesítésnek nevezett, integrált Windows hitelesítés bizton- 
ságát az adja, hogy az a felhasználó jelszavát nem küldi át a 
hálózaton. Ehelyett a felhasználó böngészője kódolt üzenet- 
váltás keretében igazolja, hogy a jelszó érvényes. 
A Kerberos v5 a Windows 2000 biztonsági architektúrájá- 
nak része. Az NTLM-et felváltó Kerberos, mint elsődleges 
biztonsági protokoll gyors bejelentkezést tesz lehetővé a 
Windows 2000 tartományba, megkímélve a felhasználót a 
különféle jelszavak és azonosítók használatától, akár tar- 
tományok között is. 
Az intergrált Windows hitelesítés a Kerberos v5 hitelesítő 
protokollt és saját Challenge/Response hitelesítő proto- 
kollját is használhatja. Ha a kiszolgálón fut az Active 
Directory és a böngésző képes a Kerberos v5 hitelesítő pro- 
tokoll használatára, akkor Kerberos, különben a hagyomá- 
nyos NTLM azonosítás használatára kerül sor. 
Bár az integrált Windows hitelesítés biztonságos, korláttal 
rendelkezik: először is csak a Microsoft Internet Explorerrel 
használhatjuk, másrészt nem működik proxy-kapcsola- 
tokon keresztül. Ennek megfelelően legjobb felhasználási 
területe az intranetes környezet, ahol mind a felhasználó, 
mind pedig a kiszolgálók ugyanabban a tartományban van- 
nak, és ahol biztosítani tudjuk, hogy minden felhasználó 
megfelelően fejlett böngészőt használjon. 


Nyílt kulcsú tanúsítványok 

Az IIS tanúsítványalapú SSL szolgáltatása egy kiszolgáló-ta- 
núsítványt, egy opcionális ügyféltanúsítványt és számos di- 
gitális kulcsot használ. Ezeket a tanúsítványokat a Microsoft 
Certificate Services-szel vagy egy külső, hitelesítést kibocsá- 
tó szervezettől (Certification Authority - CA) szerezhetjük be. 
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Tanúsítványalapú hitelesítés. 

Webkiszolgálónk Secure Sockets Layer (SSL) biztonsági hi- 
telesítését kétfajta hitelesítésre használhatjuk. A kiszolgá- 
lóhitelesítés arra való, hogy segítségével biztosítsuk a fel- 
használókat arról, hogy a webkiszolgáló biztonságos (és 
valóban az, akinek mondja magát), mielőtt ők bizalmas 
adatokat (például hitelkártyaszámot) adnának meg. Az 
ügyfélhitelesítés pedig természetesen a felhasználók sze- 
mélyazonosságának megállapítására használható. 


Kapcsolt ügyféltanúsítványok. 

Az ügyféltanúsítványokat összekapcsolhatjuk webkiszol- 
gálónk Windows felhasználói fiókjaival. Miután létrehoz- 
tunk és engedélyeztünk egy hitelesítés-fiók kapcsolatot, az 
ügyfélhitelesítéssel bejelentkező felhasználót a webkiszol- 
gáló automatikusan összekapcsolja a megfelelő Windows 
felhasználói fiókkal. Ezzel a módszerrel anélkül azonosít- 
hatjuk a bejelentkező felhasználókat, hogy basic, digest, 
vagy integrált Windows hitelesítést kellene használnunk. 
Akár egyetlen, de több ügyféltanúsítványt is rendelhetünk 
egy Windows felhasználói fiókhoz. Például ha cégünk szá- 
mos különböző osztállyal rendelkezik, vagy többféle üzlet- 
tel foglalkozik, és mindegyiknek megvan a maga webkiszol- 
gálója, a különböző osztályokhoz tartozó tanúsítványokat 
hozzákapcsolhatjuk az osztály saját webkiszolgálójához. Ily 
módon elérhetjük, hogy az osztályok webkiszolgálója csak 
a hozzá tartozó munkatársak számára lesz elérhető. 


Titkosítás 

Miután megszerveztük az információhoz történő biztonságos 
hozzáférést, az adatokat meg kell védenünk az Interneten 
történő átvitel alatt is. Az információ (hitelkártyaszám, tele- 
fonszám) biztonságos átvitele titkosítással történik. A titko- 
sítással olvashatatlan, értelmezhetetlen formába hozzuk az 
információt mielőtt elküldjük, a visszakódolással pedig 
visszanyerjük eredeti formáját. Ehhez a művelethez az IIS az 
SSL 3.0 protokollt használja fel, mely biztonságossá teszi a 
kiszolgáló és a böngésző kapcsolatát; az SSL meggyőződik 
webhelyünk hitelességéről, és azonosítja a felhasználókat. 
Az efféle kapcsolatok kiépítéséhez mind a böngészőnek, mind 
a webkiszolgálónak rendelkeznie kell megfelelő titkosító lehe- 
őségekkel. Egy biztonságos kapcsolat ideje alatt egy kulcs ké- 
szül. Mindkét fél ezt az időszakos (session) kulcsot használja 
az információ titkosítására. A kulcs biztonsági szintjét bitek- 
ben mérik; minél több bitet használ a kulcs, annál erősebb a 
titkosítás. Bár a nagyobb bitszámú kulcsot használó titkosítás 
biztonságosabb, a kiszolgálón több erőforrást fogyaszt. Web- 
iszolgálónk általában 40-bites kulcsokat használ, de akár 
128-bites is lehet, a kívánt biztonság fokától függően. 

Úgy is beállíthatjuk webkiszolgálónkat, hogy az SSL-t haszná- 
ó kapcsolathoz minimálisan 128-bites időszakos kulcshosszat 
igényeljen az alapértelmezett 40-bites helyett, bár ehhez a 
felhasználóknak megfelelő böngészővel kell rendelkezniük. 

Ha webhelyünkre a Reguire 128-bit encryption (128-bites 
titkosítást igényel) beállítást alkalmazzuk, s kiszolgálónk 
tanúsítványa 128-bitesnél kisebb kulcsokat tartalmaz, ak- 
or webhelyünk elérhetetlenné válik. 
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A webhelyek auditálása 

A biztonság utolsó bástyája webhelyünk használatának fi- 
gyelemmel kísérése. Ehhez auditáló házirendeket (audit 
policies) kell létrehoznunk a könyvtárakhoz vagy fájlokhoz 
vagy a kiszolgáló eseményeihez. Az auditáló házirendek ál- 
tal készített biztonsági naplók elemzésével juthatunk az il- 
letéktelen behatolók nyomára. 

Saját biztonsági naplóink elkészítéséhez beépített Windows 
segédprogramokat, az IIS 5.0-ba épített naplózó szolgálta- 
tásokat, vagy ASP alkalmazásokat használhatunk. Ha NTFS 
fájlrendszerrel rendelkezünk, fájl- vagy könyvtárszinten fi- 
gyelhetjük az elérésre (fájlok olvasása, írása; könyvtár bön- 
gészése) tett sikeres vagy sikertelen kísérleteket. 

A kiszolgálóval (a webkiszolgálóra történő be- és kijelentke- 
zés, a webkiszolgáló biztonsági házirendjének megváltozta- 
tása, a kiszolgáló számítógép leállítása), webhellyel, virtu- 
ális könyvtárral vagy fájllal kapcsolatos eseményeket is 
naplózhatjuk, ezt a a Microsoft Management Console Audit 
policies oldalán állíthatjuk be. 


Biztonsági varázslók 

A biztonsági beállítások megkönnyítése érdekében az IIS 
5.0 három új biztonsági varázslóval rendelkezik: 

"0 A tanúsítvány varázsló leegyszerűsíti a tanúsítványok 
kal kapcsolatos felügyeleti teendőinket (tanúsítvány- 
kérelmek készítése, a tanúsítvány életciklusának nyo- 
mon követése). A Secure Sockets Layer (SSL) protokoll 
támogatása iránt egyre növekvő az elvárás, különösen 
olyan webhelyek esetén, melyek elektronikus kereskede- 
lemmel foglalkoznak, bizalmas üzleti információkat ke- 
zelnek. Az új varázsló segít az SSL-lel működő webhely 
felállításában, ezen kívül e varázsló segítségével egy- 
szerűen alakíthatunk ki SSL-lel működő titkosítást és 
ügyféltanúsítványokon alapuló hitelesítést. A Web 
Server Certificate varázsló segítségével egyetlen prog- 
ramban szerezhetjük és állíthatjuk be, újíthatjuk meg 
kiszolgálónk tanúsítványait. 

Csak az Enterprise Certificate Server-ekhez intézhetünk 
hálózaton keresztül kéréseket kiszolgálótanúsítványok 
beszerzésére. Az IIS Web Server Certificate varázsló 
még az ugyanazon a gépen lévő, egyedülálló 
Certificate Server-t sem fogja felismerni. Mentsük a ta- 
núsítvány-kérelmet fájlba és kapcsolaton kívüli (offli- 
ne) kérésként dolgozzuk fel. Ez a hálózati kapcsolaton 
alapuló, Enterprise Certificate Server-rel intézett kérel- 
meket nem érinti. 

Ha nem hálózaton keresztül igényeljük a tanúsít- 
ványokat, akkor el kell mentenünk a kérelmet lemezre, 
s azt kell a CA-nak elküldeni. Ha megkaptuk a tanú- 
sítványt, elindíthatjuk a varázslót és ott folytathatjuk, 
ahol a kérés elmentésénél abbahagytuk. Ha a ta- 
núsítványok cseréjét írtuk elő, az IIS addig használja a 
régi kérelmet, amíg az új tanúsítvány " iránti 
kérelmünkre a CA-tól egy új tanúsítvány nem érkezik. 
Az engedélyvarázsló végiglépked az engedélyek beál- 
lításának lépésein, így könnyítve meg olyan webkiszol- 
gálók telepítését, melyek csak a megfelelő engedéllyel 
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rendelkezők számára szolgáltatnak információkat. Az 
engedélyvarázsló feladatorientált megközelítést alkal- 
maz a web és FTP engedélyek, NTFS elérési jogo- 
sultságok és hitelesítő sémák beállítására. Kiválaszt- 
hatjuk azt a beállítást, mely a legjobban megközelíti 
kívánalmainkat, s a varázsló mindent pontosan beállít: 

a web és FTP és NTFS engedélyeket, illetve a hitelesí- 

tő sémákat. A finomítást természetesen később az IIS 

beállítási lehetőségeivel mi magunk tehetjük meg. Két 
beállítási helyzet közül választhatunk: 

£ Nyilvános webhely. Ez a leggyakoribb beállítás. A 
webhely a nyilvános elérés céljából üzemel, a láto- 
gatók anonymous hitelesítéssel léphetnek be és 
minden fájlt megtekinthetnek, és elérhetik az ASP 
alkalmazásokat is. A rendszergazda minden jogot 
megkap a webhely irányítására. 

2 Biztonságos webhely. Ezt a beállítást a vállalati 
extranetek, azaz olyan intranetek használják, 
melyeket az Internetről is el lehet érni. A webhe- 
lyen lévő információ bizalmas természetű, így ez a 
beállítás Basic, Digest, vagy integrált Windows 
hitelesítést használ. Csak a jogosultsággal rendel- 
kező felhasználók számára teszi lehetővé az összes 
fájl és ASP alkalmazás elérését a webkiszolgálón. A 
fentiekhez hasonlóan a rendszergazda itt is 
teljhatalommal rendelkezik. 

0 A Certificate Trust Lists (CTL) varázsló a CTL-ek beállí- 
tásában nyújt segítséget. A CTL egy bizonyos könyvtár- 
hoz tartozó megbízható tanúsítványt kibocsátó szerve- 
zetek listája. A CTL-lel szabályozhatjuk, hogy mely CA- 
któl fogadhatunk el tanúsítványokat. Ez különösen az 
ISP-k számára fontos, akik számos webhellyel rendel- 
keznek, és mindegyik webhely különböző CA-kkal mű- 
ködik együtt. A CTL-eket csak webhelyekhez használ- 
hatjuk, FTP-helyekhez nem. 


Az alkalmazói programok környezete 

Az IIS 5.0 nagyobb teljesítményt nyújt a webalapú alkalma- 
zások készítéséhez, mint elődei. Az IIS-en belül működő 
Active Server Pages (ASP) motor, a Windows 2000 adatel- 
érést lehetővé tevő komponenseivel és komponens-szolgál- 
tatásaival kombinálva jól használható környezetet teremt a 
webalkalmazások fejlesztéséhez és működtetéséhez. 

Az ASP legfrissebb kiadását folyamatvezérlés, hibakezelés, 
Windows Script Components és más fejlesztések teszik a 
script-írók és a webes alkalmazások fejlesztői számára még 
jobban kezelhetővé. Az ASP alkalmazások gyorsaságát a 
script nélküli ASP, az automatikus teljesítményhangolás, a 
nagyobb teljesítményű objektumok és a Windows 2000 
operációs rendszer fejlesztései növelik. 


ASP-újdonságok 

Az ASP webes alkalmazások fejlesztésére szolgáló, kiszol- 
gálóoldali scriptkörnyezet, mellyel dinamikus, interaktív 
webes alkalmazásokat hozhatunk létre. Az új folyamatve- 
zérlési és hibakezelési lehetőségek megkönnyítik az alkal- 
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mazások fejlesztését és viselkedésük irányítását. A script 
nélküli ASP feldolgozás és más fejlesztések pedig az ASP 
oldalak teljesítményét növelik. 


Folyamatvezérlési lehetőségek 

Az új folyamatvezérlési lehetőségek úgy növelik az ASP-alapú 
alkalmazások teljesítményét, hogy közben csökkentik a kiszol- 
gáló és a böngésző közötti , körutazások" (roundtrip) számát. 
Átírányítás (Redirect) esetén jelenleg a Response 
.Redirect módszer használatával az oldal elérési idejét egy 
körút növeli, mivel ez esetben a kiszolgáló nem a kért 
HTML oldalt, hanem annak csak a címét küldi vissza a bön- 
gészőnek. A böngésző ekkor automatikusan elhagyja a ki- 
szolgáló kérelmi sorát, és egy új HTTP-kérelmet intéz a ki- 
szolgálónak az új URL-lel. A kiszolgáló ezt a kérelmet - 
más böngészők ugyanakkor érkező kérelmeivel együtt - 
hozzáfűzi kérelmi sorához. Egy erősen terhelt weboldal 
esetén ezek a körutazások jelentős sávszélességet pazarol- 
nak el és csökkentik a teljesítményt, különösen, ha az át- 
irányítás ugyanarra a kiszolgálóra irányul. 

Az ASP Server objektumnak két új metódusa van, melyet a 
program folyamvezérlésére használhatunk fel: a Server 
.Transfer és a Server.Execute. Ahogy az ábrán látható, a 
Server.Transfer metódust arra használhatjuk, hogy a 
Response.Redirect-tel történő átirányítás helyett a ki- 
szolgálón lévő egyik ASP-fájlról a másikra ugorjunk. A 
Server.Transfer segítségével a kiszolgáló kérelmi sorának 
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A Server.Transfer-rel megtakaríthatjuk a körutazásokat 
a kiszolgáló és a böngésző között, ha az átirányított 
URL ugyanazon a kiszolgálón lévő ASP-oldalra mutat 


Az ASP a Server.Execute metódust is a rendelkezésünkre bo- 
csátja, melyet arra használhatunk, hogy a vezérlést átadjuk 
egy fájlnak, végrehajtsuk a tartalmát, majd visszatér arra a 
fájlra mely a végrehajtást kezdeményezte. Ha otthon va- 
gyunk a VBScript-ben, akkor a Server.Execute-ot eljáráshí- 
vásként képzelhetjük el a legjobban, azzal a kivétellel, hogy 
ez esetben ASP oldalt hajtunk végre eljárás helyett. 
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Böngészőtulajdonságokat tároló komponens 

A webalkalmazások során gyakran szükség van a felhaszná- 
ló böngészőjének és tulajdonságainak pontos ismeretére. A 
webalkalmazás programozója ezekhez az információkhoz 
eddig úgy juthatott hozzá, hogy egy ügyféloldali script se- 
gítségével egy cookie-ba írta az adatokat, majd a kiszolgá- 
ló kiolvasta onnan azokat. 

A Browser Capabilities komponens BrowserType objektu- 
mát a script felhasználhatja a böngésző tulajdonságainak 
elemzésére. Amikor a böngésző a webkiszolgálóhoz kap- 
csolódik, automatikusan elküldi neki a HTTP User Agent 
fejlécet. Ebben a fejlécben a böngésző ASCII karakterlánc- 
ban definiálja önmagát, nevének és verziószámának meg- 
jelenítésével. A BrowserType objektum összehasonlítja a 
böngésző által küldött fejlécet a Browscap.ini fájlban lévő 
bejegyzésekkel. Ha egyezőt talál benne akkor a fájlban le- 
írt tulajdonságokat rendeli a böngészőhöz, ha nem talált, 
akkor hozzá hasonlót keres jokerkarakterek (,"", ,?") 
használatával. Ha így sem találta meg, akkor a 
. . Browscap.ini-fájlban beállított, alapértelmezett beállításo- 
kat fogja visszaadni. Ha nincs beállítva az alapértelmezett 
böngésző, akkor az objektum minden tulajdonságot 
UNKNOWN-ra állít be (melynek típusa string). 

A Browscap.ini fájl szerkesztésével adhatunk új böngészőket 
a listához vagy módosíthatjuk a régiek tulajdonságait. 


Hibakezelés 

Az ASP új hibakezelő lehetőségeivel könnyebben megtalál- 
hatjuk a hibákat webalkalmazásainkban. A hibákat saját 
ASP-fájlunkkal dolgozhatjuk fel, a Server.GetLastError me- 
tódussal hasznos információt (például a hibák leírását, 
vagy sorszámát) szerezhetünk. Az ASPError objektum se- 
gítségével egy ASP oldal scriptjében felmerült hiba körül- 
ményeiről kaphatunk információkat. 


Script nélküli ASP 

A megelőző verziókban minden ASP oldalt úgy kezelt a 
rendszer, hogy feltételezte: scriptet tartalmaz, s emiatt tel- 
jesítményigényes ASP feldolgozást végzett a lapon. Az IIS 
5.0 viszont először is megállapítja, hogy az ASP kiterjesz- 
tésű fájl tartalmaz-e scriptet, s ha nem, akkor statikus 
HTML oldalként kezeli, ha igen, akkor átadja az ASP-feldol- 
gozónak. Ezzel az újítással lecsökken a különbség a stati- 
kus HTML és a dinamikus ASP fájlok között, hiszen sokkal 
kevésbé kell ügyelnünk arra, hogy milyen fájlkiterjesztéssel 
hozzuk létre az oldalakat, az IIS 5.0 gondoskodik arról, 
hogy az ASP feldolgozás a lehető leghatékonyabb legyen. 


Megnövelt teljesítményű komponensek 

Az IIS 5.0-ban a fejlesztők számos népszerű komponenst 
újraírtak, ezzel lehetővé vált az alkalmazások teljesítmé- 
nyének növelése. Ezek az újraírt komponensek gyakori fel- 
adatok ellátására szolgálnak, mint például a cserélődő hir- 
detések (adrot.dll), és a böngésző jellemzőinek megállapí- 
tására szolgáló komponens (browscap.dil). 
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Az ASP automatikus finomhangolása 

Az ASP jelenlegi verziója képes észlelni, ha egy külső erő- 
forrás blokkolja a kérés végrehajtását. Ha az IIS 5.0 meta- 
adatbázisában a ASPThreadGateEnabled tulajdonság enge- 
délyezve van, akkor az ASP új végrehajtási szálakat indít a 
további kérések kielégítésére és a folyamatok folytatására. 
Ha a CPU kezd túlterhelődni, akkor az ASP csökkenti a pár- 
huzamos szálak számát. Ez csökkenti az állandó feladatvál- 
tásokból eredő terhelést, mely akkor lép fel, ha egyidejűleg 
túl sok kérést kell egyszerre feldolgozni. 

Válaszul a folytonosan változó terhelési állapotokra az IIS 
a párhuzamosan futó szálak számának szabályozásával éri 
el, hogy a kiszolgálót érő terhelés mindig optimális le- 
gyen. Az ASPThreadGateEnabled és más a párhuzamos 
szálak szabályozásával kapcsolatos tulajdonság alapértel- 
mezése a leggyakrabban előforduló kiszolgálóállapotokra 
és forgalmi helyzetekre szabott, a beállítások megváltozta- 
tása csökkentheti az IIS hatékonyságát. 

Az ASPThreadGateEnabled tulajdonság minden, a web- 
kiszolgáló folyamatában és a külön futó, csoportosított fo- 
lyamatban működő alkalmazásra hatással van. 


XML integráció 

Az Extensible Markup Language (XML) adatok vagy do- 
kumentumok bonyolult szerkezetének szemantikai leírásá- 
ra alkalmas. Ezeket a dokumentumokat aztán megoszthat- 
juk különböző alkalmazások, ügyfelek és kiszolgálók kö- 
zött. Az Internet Explorer legalább 4.0-ás verzióját hasz- 
nálva a hozzáadott Microsoft XML Parser segítségével úgy 
bővíthetjük ki webkiszolgálónk képességeit, hogy az képes 
lesz XML-formátumú adatok cseréjére az IE 4.0, vagy ké- 
sőbbi verzióival illetve más XML-feldolgozó képességekkel 
rendelkező webkiszolgálókkal. 


Windows Script komponensek 

Az ASP legújabb változatával arra is lehetőségünk nyílik, hogy 
az üzleti logikát tartalmazó script eljárásokat újrafelhasznál- 
ható COM-komponensekké alakíthassuk. Ezeket a webes alkal- 
mazásokban és más COM-alapú programokban felhasználható 
objektumokat Windows Script Components-nek nevezzük. 

A Windows Script Components VBScript-tel és az ECMA 262 
nyelvi specifikációnak megfelelő más nyelvekkel (Microsoft 
JScript? 2.0, JavaScript 1.1) felhasználásával egyszerű 
módot kínál COM-komponensek létrehozására és különbö- 
ző, COM-fogadására képes alkalmazásokban (IIS, Microsoft 
Windows Scripting Host) való felhasználására. 


Kiszolgálóoldali kiegészítések és az SRC attribútum 

A kiszolgálóoldali kiegészítések (server-side includes - SSI) 
dinamikus szöveg (például: aktuális dátum) beillesztését 
teszik lehetővé a webdokumentumokba. Az IIS 5.0-val ar- 
ra is lehetőségünk van, hogy SSI lehetőségeket használ- 
junk a ttinclude direktíva helyett ha a HTML SCRIPT tagjá- 
nak SRC attribútumát egy kiszolgálóoldali kiegészítés vir- 
tuális vagy relatív útvonalnevére állítjuk, és megadjuk a 
RUNAT-SERVER attribútumot. 


trréső 





dfessossép 
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Az ASP scriptek kódolása 

A HTML-oldalakban lévő scriptek mindig is ki voltak téve a 
kíváncsi tekinteteknek, azonban az IIS 5 tartalmaz egy új 
scriptkódoló segédprogramot, melyet a VBScript és JScript 
5.0 seript-nyelvekhez használhatunk fel. Mind az ügyfél-, 
mind a kiszolgálóoldali scripteket kódolhatjuk, olvashatat- 
lan ASCII-karakterek halmazává változtatva az értékes 
programrészleteket. A kódolt scriptek futási időben kerül- 
nek visszakódolásra. Bár ez a megoldás nem kimondottan 
titkosítás, a legtöbb felhasználót megakadályozza abban, 
hogy elolvassa és lemásolja az oldalban lévő scripteket. 


Az IIS és a Component Services 

Az IIS 4.0-nál a Microsoft Transaction Server tette lehető- 

vé a tranzakciós műveleteket, az IIS 5.0 és a Windows 2000 

esetében ezt a munkát a Component Services végzi, számos 

más, a komponensek fejlesztésével és telepítésével össze- 

függő feladat ellátásával egyetemben. Az IIS a Component 

Services alábbi lehetőségeit használja ki: 

2 Az alkalmazások különálló folyamatonkénti elszigetelése. 

2 A COM-komponensek közti kommunikáció (beleértve az 
ASP-ben lévő beépített objektumokat is). 

2" A tranzakciók koordinálása a rájuk épülő ASP-alkalma- 
zások számára. 


Összefoglalás 

Az IIS 5.0 számos ponton bővíti ki a hagyományos 
webkiszolgálókról szóló képzeteinket. Hiba esetén sokkal 
könnyebb újraindítani a kiszolgálót, így a webhelyek sokkal 
gyorsabban kerülnek ismét használható állapotba. Az alkal- 
mazások által okozott problémák immár nem jelentenek 
végzetes veszélyt a webkiszolgálóra. A múltban egy rosszul 
működő alkalmazás összeomlása akár az egész kiszolgálót 
magával ránthatta. Ma kiválaszthatjuk, hogy a teljesítmény- 
igényes, de biztonságos (minden alkalmazás külön címtérbe- 
ni futtatása) vagy a kevésbé biztonságos de hatékonyabb (a 
kevésbé fontos alkalmazások csoportjának futtatása egyetlen, 
közös folyamatban, és csak a fontosak külön folyamatban va- 
ló futtatása) védelmet választjuk-e. Még nagyobb megbízha- 
tóságot érhetünk el a Windows 2000 Advanced Server által 
nyújtott fürtözőszolgáltatás igénybevételével. A méretezhe- 
tőség is fejlődött, hiszen most már több webhelyet is fut- 
tathatunk ugyanazon a kiszolgálón. 

Az IIS telepítését és felügyeletét számos újítás teszi még 
könnyebbé: Az IIS telepítése immár részévé vált a Win- 
dows 2000 telepítési folyamatának. A karbantartás számos 
módon egyszerűsödött: a felügyeleti eszközöket egyetlen 
közös helyről lehet elérni, számos lehetőség szolgál a tá- 
voli felügyelet elvégzésére, és lehetőségünk van bizonyos 
feladatok elvégzésével más felhasználókat megbízni. A 
WebDAV támogatásával az IIS 5.0 lehetővé teszi, hogy a 
webkiszolgálón dokumentumokat érhessünk el és módo- 
síthassuk is azokat, így a vállalaton belüli együttműkö- 
dés új szintre léphet. / 

Az új biztonsági protokollok támogatásával, mint a digest 
authentication, Kerberos és a Fortezza, az IIS lehetővé teszi, 
hogy egyre biztonságosabban használhassuk az Internetet, 
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és biztonságosan telepíthessünk hálózati alkalmazásokat. 
Az alkalmazások fejlesztői minden bizonnyal tudják, hogy az 
IIS 5.0 a Microsoft Web Server korábbi változatain alapszik, 
de számos új fejlesztéssel segíti a hatékonyan működő, ru- 
galmas webhelyek és webes alkalmazások kialakítását. A fej- 
lesztések zöme az ASP folyamatvezérlés jobbítására és az 
ASP oldalak gyorsabb feldolgozására összpontosul. 

A Windows 2000 és az IIS 5.0 felhasználásával olyan lehe- 
tőséghez jutunk, mellyel mindenféle, az Internetes és 
intranetes helyekkel kapcsolatos problémát könnyűszerrel 
megoldhatunk. 


További információk: 
A Windows 2000 Server webhelye: 
http://www.microsoft.com/windows/server, 


Bevezető az IIS 5.0-hoz: 
http://www.microsoft.com/windows/server/Overview/f 
eatures/web.asp 


Az IIS SDK a Microsoft Developer Network Interneten elér- 
hető változatában: 
http://msdn.microsoft.com/library/sdkdoc/iisref/sdkt 
69f8.htm 


Microsoft TechNet IIS webhely: 
http://www.microsoft.com/technet/iis/default.htm 


A Microsoft Interactive Developer Journal-ban megjelent, 
a nternet Information Services 5.07 című cikk Interneten 
olvasható változata: 
http://www.microsoft.com/Mind/0499/IIS5/IIS5.HTM 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
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Az utóbbi években mindennapossá vált az intranetek hasz- 
nálata. Az Office Server Extensions segítségével az intranet 
egy magasabb szintre léphet - jól működő együttműködési 
környezetté válhat. Az Office Server Extensions (05E) a Mic- 
rosoft Office 2000 felhasználói számára egyszerűbbé teszi a 
meglévő webtechnológiák használatát, hogy így az intranet 
olyan együttműködési munkaterületté váljon, amely meg- 
könnyíti a felhasználók közös munkavégzését. 
Az Office dokumentumok weben történő közzététele 
ugyanolyan könnyű, mint a fájlok fájlkiszolgálóra mentése. 
A megbeszélés (Discussions) segítségével a felhasználók 
megoszthatják a dokumentum tartalmára vonatkozó elkép- 
zeléseiket, a legfontosabb webtechnológiák támogatásával 
a felhasználók könnyebben megtekinthetik és visszakeres- 
hetik a webkiszolgálókon tárolt dokumentumokat. A mar- 
ketingigazgató például létrehozhat egy marketingtervet és 
elmentheti a webkiszolgálóra, így lehetővé teheti, hogy a 
munkacsoportjába tartózó, más osztályon dolgozó tagok 
véleményezzék azt, közösen részt vegyenek a továbbfej- 
" lesztésében és a vállalati tudás felhasználásával hatéko- 
nyan létrehozhassanak egy tökéletesített tervet. 


A munkacsoport web 

Az intranethasználat előnyei közül a felhasználók általában 
azt emelik ki, hogy könnyebb a szükséges információk 
visszakeresése és elérése, mint a régebbi módszerek eseté- 
ben, amelyeknél kinyomtatott adatokat kell kezelni, vagy ki- 
szolgálócímeket kell megjegyezni. Az Internetes technológi- 
ákat használó alkalmazások figyelemmel követhetik a 
webkiszolgálón történő műveleteket, és így például jelezhe- 
tik egy felhasználónak, ha egy dokumentum tartalma meg- 
változott. Ezért aztán természetes, hogy az intranetek a 
munkacsoportok együttműködésének alapvető tényezőivé 
válhatnak. Mivel az intranetek sok hivatalos vállalati infor- 
mációt is tartalmaznak (pl. vállalati irányelveket), sok szer- 
vezet rögzített eljárást dolgozott ki az intranetre történő 
közzététel szabályozására. Néhány információ esetében ez a 
szabályozás fontos, de sok információtípus esetében nem 
szükséges. Az ellenőrzés unalmassá válhat a rendszergazda 
számára, és szűk keresztmetszetté válhat a közzététel során. 
Ez a régi módszer szükségtelen késedelmet is okozhat. 
Napjainkban a legtöbb szervezetnek részletesen kidolgozott 
eljárása van a webtartalom közzétételére. Egy munkatárs 
létrehoz valamilyen tartalmat (gyakran Office alkalmazás- 
ban), ez a tartalom a rendszergazdához kerül, aki a doku- 
mentumot más formátumúvá (pl. HTML-lé vagy PDF-fé) kon- 
vertálja, elhelyezi egy közzétételi kiszolgálón, majd pedig 
egy webhelyen. A dokumentum módosításakor, még ha csak 
egy kis sajtóhibáról van is szó, az eredeti szerző nem ren- 
delkezik jogokkal a végső dokumentum szerkesztésére. Vé- 
gig kell csinálni ugyanezt az eljárást, amely ismét ugyan- 
annyi munkát ad a rendszergazdának. Ez az eljárás szűk ke- 
resztmetszeteket hoz létre a közzététel során, amelyek ha- 
tással vannak a közzététel időszerűségére. Az eljárás egyút- 
tal azt is jelenti, hogy a tartalmat nem ismerő személy dönt 
arról, hogy a tartalom hogy jelenjen meg a weben. 
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(1. rész) 


Még ha a szerző rendelkezik is engedélyekkel a köz- 
zétett dokumentum szerkesztésére, az Office 2000 
és az Office Server Extensions nélkül a követke- 

ző problémák merülhetnek fel a webdokumen- 

tumok közzétételével és a velük való munkával 

kapcsolatban: 

-2 Nincs olyan egyszerű módszer, amellyel a 
felhasználók a webkiszolgálót használhatják. 

2 Nincs olyan egyszerű módszer, amellyel a fel- 

használók dokumentumokat tehetnek közzé egy 

webkiszolgálón. 

Nincs olyan egyszerű módszer, amellyel levezethető a 

dokumentumokkal kapcsolatos megbeszélés. 

-2 Nincs módszer a webdokumentumokkal kapcsolatos kap- 
csolat nélküli munkára. 

2 Nincs automatikus módszer a tartalom változásának kö- 
vetésére. 

Lássunk egy példát: 

2 Vállalatunk legnagyobb vevője ajánlatot kér 150 ezer 
forint értékű termékre és szolgáltatásra. A projekt ve- 
zetésére Józsit jelöljük ki az eladási osztályról, Ádám a 
pénzügyi osztályról az ajánlat jövedelmezőségéért fele- 
lős. Zsuzsa a vevőszolgálattól és Péter a termékfejlesz- 
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re, amelyet a vállalat teljesíteni is tud. 

Józsi először is egy e-mail-t küld az általa, valamint az 
Ádám, Zsuzsa és Péter által végrehajtandó feladatokról. 
Péter Józsi irányításával létrehozza az első vázlatot a 
termékajánlatról, és elmenti azt a Customer Proposal 
webmappába. Ezután Zsuzsa hozzáírja a szolgáltatások- 
ra vonatkozó részt, majd ismét a webre menti. 

Ezután Ádám átnézi ezeket, és pénzügyi analízist készít 
róluk, majd Józsi az egészet összeszerkeszti. A saját rész 
írásakor mindenki szerkesztheti és jegyzetekkel láthatja 
el a többi részt. Ezenkívül főnökeik és munkatársaik is 
írhatnak hozzá megjegyzéseket és egyéb információkat. 
Az ajánlat készítésének dinamikusan kell végbemennie, 
függetlenül attól, hogy Word dokumentum, Microsoft Excel 
munkafüzet vagy PowerPoint prezentáció formájában ké- 
szül-e. Az Office Server Extensions-szel az alkalmazottak 
egyszerűen közzétehetik ezt az ajánlatot vagy bármilyen 
más dokumentumot a weben, a tartalmat közösen hozhat- 
ják létre és láthatják el megjegyzésekkel, és értesülhetnek 
róla, ha az adatok módosulnak. A Microsoft FrontPage 
2000-rel a csoport tagjai egyszerűen létrehozhatják és ke- 
zelhetik ezeket a webhelyeket. 


Az Office Server Extensions 

Az Office Server Extensions egy webes alkalmazáskészlet, 
amely a FrontPage 2000 Server Extensions-re (amely az Office 
Server Extensions-szel együtt települ), az Active Server Pages- 
re és az ActiveX Data Objects-re (ADO) épül. Az Office Server 
Extensions az ügyféloldali szoftverekkel működik együtt az 
Office 2000-ben, a Windows Explorer-ben és a web- 
böngészőben. Az Office Server Extensions többek között az 
alábbi funkciókat biztosítja a webkiszolgáló számára: 
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"I Webes közzététel: A felhasználók a fájlokat webkiszol- 
gálókra menthetik, és könnyen megnyithatják azokat 
Office 2000 alkalmazásokkal. Olyan egyszerűen használ- 
hatják a webhelyet, mint egy fájlmegosztást. 

-" Webes megbeszélések: A felhasználók úgy vitathatják 
meg egy dokumentummal vagy annak tartalmával kap- 
csolatos elképzeléseiket, hogy az Internetböngészővel 
vagy egy Office 2000 alkalmazással megjegyzéseket ír- 
hatnak a HTML, vagy Office formátumú dokumentumok- 
hoz. A felhasználók a megjegyzésekhez is írhatnak 
megjegyzést és egyszerre is dolgozhatnak. 

0 Előfizetés és értesítések (Subscriptions and 
Notifications): A felhasználók ,előfizethetnek" egy 
webkiszolgáló megbeszéléseire, dokumentumaira vagy 
mappáira, és e-mail-ben automatikusan , értesítést" kap- 
nak, ha ezeknek a webdokumentumoknak megváltozik 
az állapota, így gyorsan reagálni tudnak az új információkra. 

0 Keresés: A felhasználók a webhelyen teljes szövegű ke- 

resést is végrehajthatnak, vagy az Office dokumentumok 

tulajdonságaira (pl. cím, szerző, kategória, kulcsszavak 
vagy egyedi tulajdonság) is kereshetnek. 

Kezdőlap: A kezdőlap egyszerű hozzáférést nyújt az 

összes Office Server Extensions funkcióhoz, és felületet 

biztosít azoknak a felhasználóknak, akik nem rendelkez- 

nek telepített Microsoft Internet Explorer 4.0 vagy 5.0 

böngészővel, illetve Office 2000-rel. 


A Kezdőoldal 
A Kezdőoldal használatával a felhasználók az Office Server 
Extensions minden funkciójához könnyen hozzáférhetnek. 
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A Kezdőoldal funkciói: 

-" Browse web Folders: A Kezdőoldal automatikusan lis- 
tát generál a web alkönyvtárairól. Így a felhasználók meg- 
tekinthetik a letölthető és megnyitható fájlok listáját. 

2 Search web Folders: A keresőoldallal a felhasználók 
Office tulajdonságok (pl. szerző, cím) vagy kulcsszavak 
alapján kereshetnek. 

2 webServer Help: HTML alapú Microsoft Súgó az Office 
Server Extensions-höz. 

0 Product Information: Hivatkozás a Microsoft Office 

Update webhelyhez, amely további információkat, le- 

töltéseket és erőforrásokat tartalmaz. 
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Egyszerű webes közzététel 

Valószínűleg az Office Server Extensions azon tulajdonságai 
hatnak leginkább a szervezetre, amelyek megkönnyítik a 
webes tartalom közzétételét. Ezek a tulajdonságok olyan 
egyszerűvé teszik a tartalom intranetre történő közzététe- 
lét, mint amilyen egyszerű a fájlok elmentése a hálózati ki- 
szolgálóra. Minden alkalmazott képes lesz intranet tartalom 
létrehozására és közzétételére. Így Péter, az előzőekben em- 
lített mérnök, az ajánlat rá eső részét ugyanolyan egyszerű- 
en mentheti el egy webhelyre, mint egy fájlkiszolgálóra, ez- 
zel lehetővé téve, hogy a megfelelő engedéllyel rendelkező 
felhasználók megtekinthessék azt. 

Az itt ismertetett funkciók olyan munkacsoportok számára 
hozzáférhetők, amelyek telepített FrontPage 2000 Server 
Extensions-t tartalmazó vagy WebDAV-ot alkalmazó webkiszol- 
gálót használnak (Microsoft Internet Explorer 5 ügyféllel). 
Ugyanakkor, ha a munkacsoport webkiszolgálója a FrontPage 
Server Extensions-t használja, a csoport tagjai további közzé- 
tételi funkciók előnyeit is kihasználhatják, így például a doku- 
mentumzárolási és helyszínkezelő eszközöket, vagy a doku- 
mentumokban található hivatkozások ellenőrzését. 


Webmappák 
Az Office Server Extensions a webkiszolgálók kezelésével 
továbbfejleszti a webes közzétételt. A felhasználók minden 
olyan hagyományos fájlműveletet elvégezhetnek a web- 
kiszolgálókon, amelyet helyi merevlemez meghajtókon és 
hálózati kiszolgálókon szoktak. Az Office 2000 alkalmazá- 
sokban és a Windows Intézőben a bővített fájlkezelő párbe- 
szédpanelek használatával kevés tanulással maximálisan ki- 
használhatják a webkiszolgálók előnyeit. 
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A felhasználók fájlokat nyithatnak meg a webkiszolgálóról, új 
és módosított fájlokat menthetnek el oda, használhatják a 
fogd és vidd" fájlműveleteket, új mappákat hozhatnak létre, 
törölhetnek és böngészhetnek az elérhető fájlok között. 


Webmappák hozzáadása 

Ezzel a funkcióval egyszerűvé válik új webmappák hozzá- 
adása a felhasználó által közzétételre gyakran használt he- 
lyek listájához. A funkció a Fájl megnyitása és a Fájl men- 
tése párbeszédpanelből, valamint a Windows Intézőből ér- 
hető el. A Fájl megnyitása és a Fájl mentése párbeszédpa- 
nelre kézzel beírt webkiszolgáló címek automatikusan beke- 
rülnek a felhasználó webmappa-listájára. 
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A Fájl megnyitása 

Hogy a webkiszolgálóhoz történő csatlakozás ugyanolyan köny- 

nyű legyen, mint a fájlkiszolgálóhoz történő, a fájl megnyitá- 

sa párbeszédpanel felsorolja azoknak a webkiszolgálóknak a 

parancsikonjait (webmappák), amelyekhez a felhasználó köz- 

zététel céljából hozzáférhet. A fájlnév mezőbe bármilyen URL 

is begépelhető, így a webhely tartalma böngészhető és a ki- 
szolgáló a webmappák felsorolásához adható. 

, Ezekkel az új közzétételi funkciókkal Józsi és csoportja 
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egyszerűen létrehozhatja és frissítheti az ajánlatot, mivel 
a friss információk bármilyen gyakorisággal könnyedén 
közzétehetők a weben. 
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HTML vagy bináris? 

Az Office Server Extensions funkciói az eredeti bináris Office 
fájlformátumokkal, a rich text format-tal (RTF) és a HTML-lel 
működnek. A szerzőnek nem kell azon gondolkodnia, hogy me- 
lyik formátumot használja az Office Server Extensions használa- 
tához - a formátum megválasztásának alapja az, hogy milyen 
alkalmazásfunkciókat igényel a tartalomhoz hozzáférő felhasz- 
náló. Az általános szabály az, hogy minél szélesebb körben ter- 
jesztjük a dokumentumot, annál fontosabb, hogy az HTML-ben 
legyen. Másrészt, ha a felhasználók dolgozni is fognak a doku- 
mentummal - nemcsak megtekintik azt - és alkalmazás-speci- 
fikus funkciókat igényelnek a kezeléséhez, a dokumentumot az 
Office alkalmazás eredeti bináris fájlformátumában kell hagyni. 


Webes megbeszélések 
A webes megbeszélések (Discussions) az Office Server 
Extensions új együttműködési funkciója. A megbeszélés so- 
rán a felhasználók új tartalom létrehozása vagy meglévő 
tartalom értékelése érdekében megjegyzéseket írhatnak a 
webdokumentumokhoz. 
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A dokumentummal kapcsolatos kérdések megbeszéléssel 
vitathatók meg. 


Miután Péter és Zsuzsa már létrehozta a termék- és szolgál- 
tatásajánlatot, Ádám átnézheti azt, és megjegyzéseket, kér- 
déseket írhat hozzá. A web Discussions használatával eze- 
ket közvetlenül a dokumentumba írhatja be. Péter és Zsuzsa 
ezután átnézheti az Ádám által felvetett kérdéseket. 

Mivel a webes megbeszélések megjegyzései egy adatbázis- 
ban tárolódnak, az eredeti webdokumentum nem változik 
meg. A megbeszélés során a munkacsoportok egyszerűen 
megvitathatják az új programokkal és termékekkel kapcso- 
latos kérdéseket. A szerző visszajelzést kap a csoporttól az 
új dokumentum közzététele előtt, majd a közzététel után 
az eredeti dokumentum megváltoztatásának veszélye nél- 
kül vállalati szinten is kaphat visszajelzéseket. Az is lehet- 
séges, hogy hálózati vagy Internet kiszolgálókon tárolt do- 
kumentumokról folytassunk megbeszélést, de ez adatvédel- 
mi okokból letiltható. Így ha például Péter a termékajánlat 
létrehozása közben meglátogatja egy versenytárs webhe- 
lyét és ott talál valami érdekeset, írhat egy olyan megjegy- 
zést, amely a helyi megbeszélési adatbázisban tárolódik. A 
csoport többi felhasználója akkor is megtekintheti ezt a 
megjegyzést, ha a versenytárs webhelyére nincs telepítve 
az Office Server Extensions. 
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A dokumentumokkal vagy weboldalakkal kapcsolatos 
megbeszélések a webböngészőből is lebonyolíthatók 








OFFICE 2000 / SERVER EXTENSIONS 


Ha a webkiszolgálóra telepítve van az Office Server 
Extensions, a felhasználók a megbeszélést mind eredeti 
Office dokumentumok, mind HTML fájlok esetében lebonyo- 
líthatják. A megjegyzések az Office 2000 egy speciális esz- 
köztárának használatával mind Office alkalmazásokkal, 
mind a böngészővel hozzáadhatók, vagy akkor is, ha a fel- 
használó a megbeszélést a Kezdőlapon keresztül éri el. Mint 
az előző ábrán látható, a megbeszélés a dokumentumon be- 
lül vagy átfogó megbeszélésként is megtekinthető, amely a 
lap alján található Discussion panelen keresztül érhető el. 
A Discussions eszköztár használatával a felhasználók új 
megjegyzéseket szúrhatnak be; megtekinthetik, szerkeszt- 
hetik és megválaszolhatják a meglévő megjegyzéseket; elő- 
fizethetnek egy adott dokumentumra és megtekinthetik 
vagy elrejthetik a Discussions ablakot. 

Az Internet Explorer 4.0-ban vagy 5-ben és a Microsoft 
Word-ben a megjegyzések az alatt a bekezdés alatt jelennek 
meg, amelyre vonatkoznak. Ha a böngésző Internet Explorer 
3.0 vagy Netscape Navigator, a felhasználó a Kezdőlapra lép 
be, és a kiszolgáló létrehoz egy alsó keretet a megjegyzések 
számára. Az Office Server Extensions telepítésével a munka- 
csoportok számára lehetővé válik, hogy tagjaik önállóan és 
akár egyidejűleg dolgozhassanak együtt a webkiszolgáló 
bármely Office vagy HTML dokumentumán. 


A web megbeszélések adatbázisa 

Az Office Server Extensions a megjegyzéseket a dokumen- 

tumoktól külön, egy saját adatbázisban tárolja. Ez az archi- 

tektúra a következő előnyökkel jár: 

7" Megmarad az eredeti dokumentum. Az eredeti doku- 
mentumhoz ténylegesen semmi sem adódik hozzá és 
semmi sem változik meg benne. A megbeszélések 
adatbázisa tárol minden megjegyzést, valamint azt is, 
hogy az adott megjegyzés a dokumentumon belül ho- 
vá kapcsolódik. 

-" Nem mindenki látja a megbeszélést, aki megtekin- 
ti a weboldalt, dokumentumot vagy más tartalmat. 
A megbeszélések adatbázisának adatvédelme külön ke- 
zelhető a web fájlengedélyeitől. Ez egy speciális, 
Collaborators nevű felhasználói csoport használatával 
érhető el, amely a felhasználóknak jogot biztosít a ki- 
szolgáló böngészéséhez és a web megbeszélésekben va- 
ló részvételhez, de nem ad más jogot a kiszolgáló keze- 
léséhez. Azok a felhasználók, akik nem rendelkeznek 
engedéllyel egy adott dokumentum szerkesztésére, így 
engedélyt kaphatnak a dokumentum megtekintésére és 
a megbeszélésen való részvételre. 

7 A felhasználók egyidejűleg készíthetnek megjegy- 
zéseket egy adott webdokumentumhoz. Mivel a web 
Discussion adatbázis többfelhasználós, egy időben 
több felhasználó készíthet megjegyzéseket egy doku- 
mentumhoz. Mivel maga a dokumentum nem változik, 
nincs szükség a verziók kezelésére. Egy szervezetben 
létrehozható egy központi megbeszélési kiszolgáló, így 
mindenki részt vehet a munkában. Ez lehetővé teszi, 
hogy a felhasználók kevés adminisztratív munkával ve- 
gyenek részt a megbeszélésekben. Ha korlátozni akar- 
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juk, hogy ki vehessen részt egy adott megbeszélésen, 
különböző webeken több megbeszélési adatbázisra van 
szükségünk. A felhasználók a Discussion Options menü- 
jében kiválaszthatják, hogy melyik megbeszélési adatbá- 
zist kívánják használni. Egy másik megbeszélésen való 
részvételhez a felhasználónak egy másik kiszolgálót 
kell választania. A felhasználói csoportok számára a 
rendszergazda hozhatja létre ezt a beállítást és az 
Office 2000 telepítésekor telepítheti ezt is az Office 
Profile Wizard használatával. Az Office Profile Wizard-ról 
részletesen a Microsoft Office 2000 Resource Kit-ben 
vagy az Office 2000 Deployment and Maintenance le- 
írásban olvashatunk. 
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Alapértelmezésben a megbeszélések a Microsoft Data 
Engine-ben (MSDE) tárolódnak, amely egy 10099-osan Mic- 
rosoft SOL Server kompatíbilis adatbáziskezelő. Az MSDE 
akkor települ, ha semmilyen más SOL Server adatbázis 
nincs a webkiszolgálóra telepítve. 

Ha rendelkezünk telepített SOL Server 6.5-tel (vagy ennél 
újabb verzióval) az Office Server Extensions-t tartalmazó ki- 
szolgálón, vagy az távolról elérhető a hálózaton, azt is 
használhatjuk az Office Server Extensions megbeszélési 
adatok tárolására. A távoli adatbázis eléréséhez az Office 
Server Extensions-t a ,no database" beállítással telepítsük. 
Így nem települ az MSDE, és a rendszergazdának lehetősé- 
ge nyílik arra, hogy a telepítés befejezése után más adat- 
bázist válasszon. Ha meglévő SOL Server adatbázist haszná- 
lunk megbeszélési adatbázisként, azt együtt kezelhetjük a - 
többi SOL Server adatbázis adatával. Az MSDE önszabályo- 
zó, és rendelkezik egy olyan segédprogrammal is, amellyel 
az Office Server Extensions elmentheti a megbeszélési adat- 
bázisokat. Ha az MSDE-ről később át szeretnénk térni az 
SOL Server 7.0-ra, ezt egyszerűen az SOL Server 7.0 telepí- 
tésével tehetjük meg. A megbeszélési adatbázis részletezé- 
séért lásd a Microsoft Office 2000 Resource Kit-et. 


Előfizetés és értesítés 

A felhasználóknak tudniuk kell, hogy a legfrissebb tarta- 
lommal dolgoznak-e. A programok és a megbeszélések na- 
ponta változnak, de mindenkinek ugyanazzal az informáci- 
óval kell dolgoznia. 

Az Office Server Extensions előfizetés (Subscription) funk- 
ciójával a felhasználók előfizethetnek egy dokumentumra, 
mappára vagy megbeszélésre, és így e-mail-ben , értesítést" 
kapnak, ha az módosul. A felhasználók az értesítés gyako- 
riságát is meghatározhatják, így idejében értesülnek arról, 
ha megváltozik egy megbeszélés, fájl vagy mappa tartalma, 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 


"Gtic 


de nem kapnak túl sok e-mail-t és a dokumentumokat sem 
kell rendszeresen ellenőrizniük. A csoport tagjai a legfris- 
sebb információhoz jutnak hozzá, a hozzászólások pedig 
gyorsan és hatékonyan összegyűjthetők. 

Tegyük fel, hogy Péter, Józsi, Zsuzsa és Ádám mind előfizet- 
tek a Customer Proposal webmappára. Amikor Péter befejez- 
te a termékajánlatot, mindannyian értesítést kapnak arról, 
hogy elmentette azt a webre, így Zsuzsa azonnal hozzáírhat- 
ja a saját részét és a Péterével kapcsolatos megjegyzéseit. 
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szorProp was created 
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Ez az e-mail üzenet értesíti a címzettet arról, hogy a 
TRPCustomerProp dokumentum bekerült a CustomerProp 
webes munkacsoportba. Az üzenet közvetlen hivatkozást 
tartalmaz a dokumentumra. 
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Az előfizetés egyszerű művelet 

Az adatvédelem tervezésénél vegyük figyelembe, hogy ha 
egy webkiszolgálón engedélyezzük az előfizetést, a fel- 
használók olyan mappákra is előfizethetnek, amelyekhez 
nem rendelkeznek olvasási engedéllyel, és így értesítést 
kapnak azok változásairól. Ezzel nem változnak meg a fel- 
használók fájlengedélyei, de figyelemmel kísérhetik a 
fájlok módosításait. 


Dokumentumok böngészése, keresése és elérése 

Néhány évvel ezelőtt könnyebb volt az Interneten informá- 
ciókat megtalálni, mint a legtöbb szervezetben. Azóta a 
szervezetek nagy része webes technológiákat használ az in- 
formációk belső keresésére. Bár így a felhasználók képesek 
kulcsszavakkal keresni, továbbra sem tudnak egy webmap- 
pában böngészni mondjuk a Microsoft Word-ből vagy Excel- 
ből, és nem rendelkeznek egységes kezdőhellyel sem. Az 
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Office Server Extensions a Microsoft Index Server-t használja, 
és saját maga is telepít egyéb olyan technológiákat, amelyek- 
kel a felhasználók egyszerűen megtekinthetik, kereshetik és ke- 
zelhetik a webkiszolgálók dokumentumait. Ha például Péter, 
Zsuzsa, Ádám és Józsi munkatársai vagy főnökei meg akarják 
tekinteni az ajánlatot, és engedéllyel is rendelkeznek ehhez, de 
nem találnak rá hivatkozást, a webhelyen megkereshetik azt. 


Az AutoNavigation oldalak 

A tipikus HTML dokumentum csatolt objektumokat vagy képe- 
ket is tartalmaz. Egy HTML dokumentum mappája egy HTML 
dokumentumot és akár húsz vagy több képfájlt is tartalmaz- 
hat, és ez elriaszthatja a felhasználókat attól, hogy megte- 
kintsék egy webmappa tartalmát és kiválasszák a szerkeszten- 
dő fájlt. Az AutoNavigation oldalak használatával az alábbi 
nézet segítségével a szerző egyszerűen kiválaszthatja a szá- 
mára szükséges fájltípusokat, így egyszerűbbé válik a weben 
már közzétett dokumentumok szerkesztése. 
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Web listing for localhost - /BDM Client/ folder: 
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Abnett tazá 8 


a Haza 
Az AutoNavigation oldalak egyszerűvé teszik a doku- 
mentumok keresését a webhelyen. 
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Az AutoNavigation oldalak az intranet igényei szerint 
testreszabhatók. 


Keresés 

Az Office Server Extensions egy keresőoldalt is telepít a ki- 
szolgálóra, és azt a Kezdőoldalhoz csatolja. A keresőoldal 
a Microsoft Index Server-t használja, így nem használható, 
ha az nincs telepítve. Ha az Index Server-t később hozzá- 
adjuk, a hivatkozás használhatóvá válik, és a felhasználók 
hozzáférhetnek a keresési funkcióhoz. A keresőoldal egy 
ASP oldal, tehát böngészővel használhatjuk. A webkiszol- 
gáló dokumentumait ezután a hagyományos fájltulajdon- 
ságok (pl. név) vagy hagyományos és egyedi Office tulaj- 
donságok alapján is kereshetik. 


Folytatjuk... 
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BILL GATES MOND 


A .NET felülettel kapcsolatban nemrégiben azon 
töprengtem, hogy hogyan lehetne a sajtó figyel- 
mét felhívni erre a technológiára, mert sajnos 
ez is csak annyira érdekli őket, mint a szemét- 
szedés - hogyan lehetne a sajtót valaha is rá- 
venni, hogy vezércikket írjon a szemétszedés- 
ről? Szerencsére végül az Oracle megoldotta a 
problémát, és rövid időre ugyan, de címlapra ke- 
rült szemétszedési technológiájuk. (Bill Gates itt 
az Oracle által felbérelt, de lebukott magánnyomozók 
ténykedésére utal - a ford.) 
A .NET technológia olyan felületet és eszközkészletet jelent, 
amelynek komponensei részben az Interneten, részben külön- 
böző hardvereszközökön futnak. Az elsődleges eszköz termé- 
szetesen továbbra is a számítógép, ezeken futnak a kiszolgá- 
lószoftverek, ezek a biztonsági rendszer alappillérei. Az in- 
formációk elérése pedig bármilyen eszközzel megvalósítható. 
Mostanában mindenki , digitális világban" gondolkodik. Ez 
egy olyan világ, ahol fényképeinket bárkinek megmutathat- 
juk, az általunk kedvelt zenéket gyorsan megszerezhetjük - 
sőt, még fizetni is milyen könnyű a weben! Vagy vegyük pél- 
dául a videót. Már csak az adatok mennyisége, és a sebes- 
ségigény miatt is ez az egyik legbonyolultabb adat, amit 
számítógépeinkkel kezelni kell, mégis nagy szükség lehet ar- 
ra, hogy a felvételeket könnyen és egyszerűen vihessük el 
egyik helyről a másikra. Előfordulhat, hogy valaki nem tud 
megjelenni egy értekezleten - ekkor jól jöhet egy videóka- 
mera, és később az értekezlet videóanyagát, vagy annak egy 
részletét el lehet küldeni e-mail-ben. Ugyanezt a felvételt 
esetleg a későbbiekben vissza lehet keresni, és az általunk 
érdekesnek tartott részleteket vissza lehet nézni. 
A jegyzetelést is szeretnénk egyre inkább átültetni digitális 
formába. A személyi számítógépek egy új formája, a Tablet PC 
már ennek a jegyében születik - a .NET generáció gyermeke. 
Ez az az eszköz, amivel végleg vége a papírmunkának, és vég- 
legesen beléphetünk a digitális világba. De ahhoz, hogy ez 
megvalósuljon, nagyon fontos, hogy a képernyő tökéletesen 
olvasható legyen. Ezzel kapcsolatban rengeteg kutatást végez- 
tünk. Meg kell találnunk azt a felbontást, ami olvashatóság 
szempontjából az LCD képernyő képét a legközelebb hozza a 
papír által nyújtott ,élményhez". 
A hardveriparban dolgozó partnereinknek köszönhetően az 
év végére a kezünkben lesz a Tablet PC prototípusa, amely 
előreláthatólag a következő évben jelenik meg az üzletek- 
ben. A Tablet PC képernyője egyszerűen lenyűgöző lesz. Az 
ötlet, hogy számítógépet használjunk papír helyett hason- 
ló, mint a Power Point használata diafilm helyett, csak a 
hatás sokkal drámaibb lesz. 
A mi célunk az, hogy az előbb említett dolgok mellett az 
egész üzleti élet átkerüljön digitális keretek közé. Ha tüzete- 
sebben megvizsgáljuk a napjainkban zajló elektronikus keres- 
kedelmet, akkor az derül ki, hogy az úgynevezett e-com- 
merce üzletkötésekben még mindig jelentős szerep hárul a 
hagyományos folyamatokra. Az eladó és a vevő például sok- 
szor nem az Internet segítségével talál egymásra, vagy pél- 
dául az üzlet pénzügyi része már nem az Interneten köttetik. 
Az emberek ugyanígy nem használják az internetes rendelést, 
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ha a folyamatba bármilyen hiba becsúszhat, például kétséges 
a termék minősége, késhet a szállítás, vagy túl nagy pénzek 
forognak kockán - ilyenkor inkább felveszik a telefont. A két 
világ találkozása és keveredése azonban még nagyobb meg- 
bízhatatlansághoz vezethet. 

Ahhoz, hogy a szolgáltatás teljes menete on-line menjen 

végbe, sokkal erősebb infrastruktúra szükséges, melynek 
alapköve a BizTalk Server lehet, mellyel az egész tranzakció 
menetét lépésről lépésre nyomon tudjuk követni. Így még 

az is, aki nem ért a számítástechnikához, könnyen átlátja, 
és képessé válik folyamatok kézbentartására. 

Ha ma megnézzük akár egy vállalat, vagy egy kezdő felhasz- 
náló honlapját, és megvizsgáljuk a kódot, vagy az állomá- 
nyok kezelésének módját, láthatjuk, hogy bonyolultságuk 
miatt nem elég hatékonyak a rendszer elvárásaihoz képest. 
Ez volt az oka annak, hogy elgondolkoztam azon, milyen 
technikai háttérrel lehetne az alkalmazások megírását le- 
egyszerűsíteni. A következő kérdésem az volt, hogy milyen 

módszerrel lehetne a különböző eszközöket összefogni. És 
ekkor jött képbe a .NET. 

Az ötlet nem sokban különbözik a Microsoft 25 évvel ez- 
előtti alapötletétől, hisz itt is mindennek a központja a PC. 

( :-) - a ford.) Az ötlet akkoriban arról szólt, hogy virágzó 
szoftveripar kiépítéséhez milliónyi személyi számítógépre 
van szükség. A Microsoft alapításának idején rendkívül ke- 
vesen voltak a szoftveriparban, egy aprócska üzletág volt az 
egész; nagyon kevés dolgot adtunk el - viszont nagyon drá- 
gán. Arról álmodoztunk, hogy egyszer majd az informatika 
óriási iparággá válik. Nem is számítottunk arra a robbanás- 
szerű fejlődésre, amit a különböző gyártóktól érkező gépek 
tökéletesen kompatíbilis működése, így az együttműködés 
kiszélesedése idézett elő. A Basic fejlesztéséről hamarosan 
átálltunk operációs rendszerek készítésére, s 1981-ben ki- 
adtuk az MS-DOS-t. Most, a Windows korában alkalmazások 
ezrei közül válogathatunk. Ez mind annak köszönhető, hogy 
ma már az alacsony ár - sok termék filozófia szerint dolgo- 
zunk. A szoftveriparnak megvan az a jó tulajdonsága, hogy 
több termék előállítása nem ugyanolyan mértékben növeli - 
a költségeket, mint más iparágakban. Ez alacsonyabb árat 
generál, ami több termék előállítását jelenti... ez a körfor- 
gás mozgatja a PC ipart. A számítógépek millióinak össze- 
kapcsolódásával a forgalom még tovább fog nőni. 

A számítógépiparra most óriási figyelem összpontosul. A Micro- 

soft a múltkor cégvezetőket hívott össze, hogy megbeszélje ve- 
lük az irodai munka és a webes felületek kezelésének átalaku- 
lását, és azt láttuk, hogy a vezetőket igencsak érdekli a téma. 

A PC megjelenésekor csak nagyon kevés ember értette, 

hogy miről is van szó tulajdonképpen. Manapság ha kinyi- 
tunk egy újságot, vagy bekapcsoljuk a tévét, másról se hal- 
lani. Mára a számítógép abszolút a média részévé vált, s in- 
nen csak egy lépés, hogy az életünk részévé váljon. 
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Hivatalos Microsoft oktatásokkal (Windows 2000, SOL Server 
IIS...stb.) és egyedi tanfolyamokkal (fürtözött rendszerek, háló- 
Zatbiztonság, Active Directory , mélyvíz". . .stb.) a NetAcademia 
Kft. lehetőséget nyújt Önnek és munkatársainak, hogy lépést 
tartson a legfrissebb szoftverújdonságokkal. 

Tanfolyamainkon magasan képzett szakemberek segítségével 
sajátíthatják el a legújabb szoftverek , csínját bínját" a legjobb 
informatikusok, tehát Önök! Tematikus levelezési listánkon, a 
http://www.netacademia.net címen segítségül hívhat több 
száz szakembert, hogy kérdéseire közösen megtalálják 

a legjobb megoldást. 

Maradjon a legjobbak között! 

Keressen minket: www.netacademia.net 

Jelentkezzen tanfolyamainkra a 


tanfolyamenetacademia.net címen. 


www.netacademia. net 


1105 Budapest, Ihász utca 13. " Tel.:263-2732 





